When Direct3D was introduced there was no Glide nor MiniGL and OpenGL provided more than enough of the functionality games would need at the time. Microsoft was in control of their OpenGL implementation which allowed both a full replacement (what drivers do nowadays) but also a partial replacement where a driver would only implement a tiny subset of the API and the rest (e.g. transformation, clipping, lighting, etc) would be handled by Microsoft's code.

> In order to migrate gaming from DOS to Windows, Microsoft was in dire need for a reliable and widely available API that they could ship with the OS for game developers to use.

Yes, the rest of DirectX provided that and OpenGL games used it too.

> OpenGL wasn't exactly great, since it wasn't controlled by MS

Which was the only real problem for Microsoft, not anything else

> and the whole extension system was a huge mess

During the mid to late 90s there were barely any extensions and OpenGL 1.1 provided more than enough functionality for the games at the time. The main extension that would be needed during the very late 90s was multitexturing which was importing a few function pointers, nothing "messy".

> and horrible to work with

Compared to early Direct3D, OpenGL was much easier to work with - early Direct3D required to build execute buffers, manage texture loss yourself and other nonsense whereas OpenGL allowed you to essentially say "use this texture, draw these triangles". This was such a big issue with Direct3D's usability that Microsoft eventually added similar functionality to Direct3D in versions 5 and 6 and they even killed execute buffers pretty much instantly. Even then OpenGL still provided more functionality that the drivers were taking advantage as new functionality was available in GPUs (e.g. Direct3D 7 introduced hardware transformation and lighting, but OpenGL had this from day one essentially so all games that used OpenGL got T&L for free when drivers added support, whereas games that used Direct3D had to explicitly enable it).

> Direct3D on the other hand offered a stable API and most importantly a REFERENCE RENDERER! - something that OpenGL was lacking and lead to super annoying bugs

This is wrong, Microsoft had a software rasterizer for OpenGL 1.1 that behaved very close to the spec and SGI had also released their own software rasterizer.

> since every other driver behaved differently...

This was the case with Direct3D too and in fact a much more painful experience. Direct3D tried to alleviate this by introducing capability flags but in practice no game did proper use of them and games had all sorts of bugs and issues (e.g. DF Retro had a video where they tested a bunch of 90s 3D cards on Direct3D games and pretty much all of them had different visual glitches).

> OpenGL lacks a defined reference implementation, so "OpenGL support" on the box means very little in practise

This is an issue indeed, though it is largely a problem with the driver developers not caring about providing a consistent behavior than a problem with the API. If the driver developers cared they'd try to do things similar to other drivers as long as any difference was spotted between implementations.

Though that is a modern issue, for pretty much the entirety of the 90s and early 2000s there were official software rasterizers from both Microsoft and SGI.