This might be motivated by Windows licensing regime. Licensing for Windows VM instances used to be super-painful, so people would try hard to avoid it.
IIRC, to run a Windows VM you were required to acquire Windows Datacenter licenses for every node capable of running that VM (at least that's what we were told). If you have a fleet of hypervisor nodes running Linux workloads, the licensing cost calculated for a single Windows VM was absolutely ridiculous.
I guess things are less insane today and you can just get a license for the guest OS, no matter whether it's running virtualized or bare metal?
What you’d need to run any Windows program is a way to parse the PE executable format, load it into memory, and emulate or simulate W32 api calls. I’m sure there are other steps but I can’t think of many more off the top of my head.
At work, the problem is different - even if ReactOS achieved 100% bug-for-bug compatibility with Windows 10, using it on client PCs would be too painful, because every time some application misbehaved, there would be that lingering doubt if the problem is with the application itself or with the OS. And if you called some software vendor's support hotline, the moment you let it slip that you are running something that is not Windows, they would start laughing and hang up on you.
There are scenarios where I would consider a Windows 10-compatible ReactOS at work - e.g. for reviving a PC where the "native" Windows version has gone out of support, and it only needs to run MS Office or Windows' RDP client, or a browser. But in the five years I have worked as Windows admin, this has happened so rarely I doubt it would matter a lot.
If the project got to the point where ISV's support hotlines did not care whether you are running MS Windows or ReactOS, ... that would change things in a big way.
Not that that should be the primary motivation for writing it, but surely the validation won't hurt! Projects like these are the most interesting ones for me to read!