LibreSSL is a fork for OpenBSD and doesn't have all the functionality of openSSL (e.g., no Windows support), so it's not a given that LibreSSL will actually become the standard. Also, despite the issues with openSSL, there is significant name recognition for it. That means that funding and improving openSSL can potentially lead to a better outcome than funding libreSSL. I mean this in the sense that funding something else (e.g., LibreSSL) could result in a situation where people still use openSSL because they know the name but that the improvements are going elsewhere. Sure, you can say that people should switch, but name recognition can be tough to overcome.
I think as long as LibreSSL plans on ripping out the FIPS stuff, it's not going to replace OpenSSL in a huge number of places. Don't get me wrong, I think it's the right decision for the OpenBSD guys, and for the security of the library, but it's definitely going to limit adoption.
FIPS support is such a rare requirement (and such an awful one) that I'm willing to bet LibreSSL, once it's 'finished' and buildable on the typical Linux system, will be gladly adopted by pretty much everyone who can. Distros will probably prefer LibreSSL whenever possible, with the exception of Debian, unless the licensing issue can be resolved (which I hope it is because GnuTLS is awful).
The vast majority of people who use OpenSSL don't need FIPS compliance, and LibreSSL will provide them with a more solid, better reviewed, more secure, lightweight, reliable drop-in replacement. It's hard to argue with that.
To make the code auditing easier a number of code paths irrelevant to OpenBSD were removed.
Once the code is audited and bugs corrected portability is next. This will only happen if the right team is in place, the community wants it, and sufficient funding is secured.
That's not exactly accurate. In its current form, you couldn't compile OpenBSD's libssl on Windows even if you had a build system for it.
However, I don't think this is a bad thing. To do a massive clean up, you must be able to focus on code that you can actually compile and test. Dead code, code behind ifdefs is likely to rot. If it wasn't very rotten already.
It is better to do a fresh port of a cleaned up code base for modern systems.
