In CreateRunspacesForUseWindowsPowerShellParameterSet() we request connectionInfo.PSVersion = new Version(5, 1)
This is not enough?

Unfortunately, not enough. Error is generated too late - when remote WinPS process is already starting and parsing arguments and Job's code (that we are reusing in WinCompat and that starts remote process) not doing a great job at reporting it, so user experience is not good - user gets an impression that everything is fine, when in fact WinCompat is not working.
Also, detecting the incompatible environment and reporting a clear error sooner than later is better performance-wise.

I guess most of user systems already have PS 5.1 so version check is an edge case.
I guess PowerShell processes Version parameter before other parameters so it doesn't extra work.
Also I think it is useful to catch Windows PowerShell exit code and write an error if needed - do we this? In PR case we could catch -1 exit code, catch message "Cannot start Windows PowerShell. No version of Windows PowerShell compatible to 5.1 is installed." and then write appropriate error to user.

You are right, theoretically on the high level that's probably the right approach. The devil is in details, special-casing WinCompat needs small changes in remoting code and it is already complex-enough. Just for the risk of regressions in high-use features (remoting, jobs) I would like to avoid doing changes in remoting code unless absolutely necessary.