After investigation, it turns out that the problem is that LFS is D3D9 application, while OpenVR requires D3D11. To workaround this problem LFS uses DXGI shared resources feature, sharing texture from D3D9 to separate D3D11 device created inside LFSOpenVR.dll. Shared resources are sadly not implemented in DXVK.
I'm not familiar enough with DXVK codebase to add proper support for shared resources, but workaround is possible: note that the only thing done with shared texture on the D3D11 side is passing to IVRCompositor::Submit, which on Linux side just pulls real Vulkan texture from it and bridges call to real OpenVR library on the host. Thus whether texture originated from D3D9 or D3D11 doesn't really matter.
To take advantage of this, we need to do:
Add Vulkan COM interop interfaces to DXVK D3D9 texture object, so Proton OpenVR bridge can just read Vulkan image data from it the same way it does with D3D11 textures:
https://github.com/Milek7/dxvk/commit/1fbeab2bc7be7465ed8cec0d97bb156ff7b86903
With these modifications LFS could now just pass D3D9 texture handle directly into OpenVR, hovewer it doesn't know about this and tries to use unimplemented shared resource API. One issue is that pointer passed to LFSOpenVR.dll comes from pSharedHandle argument from D3D9DeviceEx::CreateTexture, which DXVK sets to NULL. LFS.exe would need to be patched to use ppTexture instead, or as we already compile modified DXVK, just add workaround for this:
https://github.com/Milek7/dxvk/commit/96f21f613d114a03c4c6c2ba1c4c295afee877c6
Last issue is that LFSOpenVR.dll still tries to create D3D11 device and use handle obtained from unimplemented GetSharedHandle. We need to inhibit this behaviour, and it seems LFSOpenVR.dll already supports using texture directly without additional D3D11 device. To use this feature we could create interposer DLL that tweaks structure passed into LFSVR_QueryHMD by writing non-zero value into (int*)arg+8. Alternatively we can patch LFSOpenVR.dll, and I went with this approach: inside LFSVR_QueryHMD I replaced JZ instruction with bytes 0F 84 B2 02 00 00 with appropriately sized NOP (eg. 66 0F 1F 44 00 00).
With above modifications LFS VR works on Proton.
EDIT: One more thing. LFSVR_AcceptSharedTexture in LFSOpenVR.dll tries to read texture size for writing into log file from what it thinks is ID3D11Texture2D, but after our changes it's IDirect3DTexture9. It seems to luckily only print junk into log file, but for correctness it should be patched to return early there. Patch EB 68 to E9 FB 00 00 00 (overwrite trailing bytes). SHA256 after patches is 0012e00e604379821b977df784917ed1d944ae8bcfd09dfe353ec38849e359f5.
PS: Patches described above were tested on 0.6U13.