I know wine itself has been heading toward more separation of the PE/posix syscall approach. But I thought the motive for that was mostly about WoW64 thunks (let a 32-bit Win32 process make syscalls that invoke 64-bit linux dependencies, so the distribution doesn't need much in the way of 32-bit linux dependencies). I get why this is good for the parts of wine that are mimicking microsoft ntdll//win32u boundaries, but if the plan is to eventually remove all support for https://wiki.winehq.org/Winelib, that's news to me, and rather unwelcome news at that.
It would not be easy to migrate our usage to PE; to start with, wine doesn't come with a C++ standard library the way it comes with a replacement msvcrt.dll, and our target is a Yocto system that doesn't currently have mingw or clang. Now, adding more toolchains is certainly possible in principle, and I suppose wine does come with a runtime for the few parts of msvcp* that are not inline/templates, so it might be possible to use that along with headers from https://github.com/microsoft/STL (which is even MIT licensed). But that's a fair amount of work, and the result would be a C++ runtime whose ABI doesn't match anything else on the linux system.
So that wouldn't really suit our purpose as well as today's winelib setup does - in a .dll.so, one can use wineg++, and glibc, and libstdc++, and ends up with an environment in which the same code can more-or-less freely use Win32 API while also linking to and even inheriting from classes in native linux libraries. You have to be a little careful about calling conventions, but it's still very low-friction to have what is substantially a native linux class that also happens to do things like expose like COM/oleaut interfaces. This is not wine's own use case, but it's been a good fit for us. Turning every point that crosses those boundaries into a syscall would require a ton of boilerplate.
But it's certainly true that the less wine uses "builtin" DLLs itself, the less relevant this patch is to wine itself. And it started out being not especially important since wine doesn't write its dlls in c++, either. This is not quite a c++-only thing - libc_nonshared.a uses it to implement a few things like atexit or at_quick_exit too, and wine seems to have a few users of that (they might all be msvcrt by now, though). But C++ destructors are the main case where idiomatic [RAII](https://en.cppreference.com/w/cpp/language/raii)code uses lots of user-defined code registered to run at module unload.
So this is definitely a patch we want; it lets c++ code that works in mingw or msvc also work in wineg++, by giving the library unload the same sequence of events it has in PE (atexit functions and destructors run during DLL_PROCESS_DETACH, and this is achieved using a DllMainCrtStartup). And it wasn't very invasive, and makes for one less thing that is subtly different between .dll.so and .dll files. So it seemed worth proposing.