Great feedback from Scott Fierro. I'll comment on the questions:
1) Join Site does work between operating system versions. It briefly states that in the bug, but we can certainly call it out better:
Perhaps you’re experiencing hardware performance issues, or you want to run a newer operating system.
2) The DR tool requires Portal, and as Scott Fierro indicates, the approach is more complex than the first option. The use of the etc\hosts file can get around some of the requirements of the tool, (for example that the front-end URLs are the same). That way you don't have to worry about DNS and how traffic is routed, nor how to migrate content between deployments that have different URLs. This is described in the Etc\hosts file section:
Etc\hosts file
A quick word on the use of the etc\hosts file, located under C:\Windows\System32\drivers\etc on Windows and the \etc folder on Linux: it’s used to resolve hostnames by entering IP addresses and associating the IP addresses to hostnames.
For example, if my machine name has an IP address of 10.0.0.1 and is resolved to enterprise.domain.com via DNS, I can add an entry to the etc\hosts file on the machine to resolve the machine’s IP address to a different hostname:
10.0.0.1 alias.domain.com
If I ping alias.domain.com in a command prompt the etc\hosts file is resolving alias.domain.com to 10.0.0.1, which is enterprise.domain.com. If I had a web server running on the machine, I can reach the web server via alias.domain.com or enterprise.domain.com.
This approach is slightly more complicated than migrating using the Join Site workflow as the steps are dependent on your deployment type and requires modifying the etc\hosts file to manage hostname resolution.
This approach is useful if you need to maintain availability during the migration as you can stand up that separate environment without causing downtime for your production environment.
Honestly, I wouldn't suggest setting up a new system with new URLs and migrating content over. Assuming you'll be using the same URLs are previously, this is how I'd foresee this going:
1) Set up your new environment using new URLs
2) Use the Python API, specifically the ability to migrate content between environments, to move stuff from your old environment to your new environment. Hosted services would need to be republished.
3) Since there's no easy way to update the URLs of existing content, you'll need to set up another new environment that uses the same original URLs.
4) Move everything back to the original environment to use the correct URLs
If you don't intend on using the same URLs, (which is unlikely as you're simply looking to migrate to new machines), then you wouldn't have to worry about 3 and 4.