Valve Is Working on Another Extension to Help in Direct3D-over-Vulkan

Simple, private ownership structure stemming from bootstrapping. Any presence of external equity or (worse) publicly traded shares would make it impossible to ever consider the money printing machine that the steam store is "good enough" for now and focus on long term strategy instead. Perhaps even allowing certain forms of "benevolence". Companies with private, noninstitutional owners can be infinitely greedy as well, but they don't have to be. Contrast this with publicly traded: there, if there is any reason to believe that more could be earned, someone ruthless/optimistic enough to believe this will bid more for ownership than those who don't and eventually the company is forced to go the ruthless path due to it's ownership structure.

If there were shares traded of a goose that lays golden eggs, the shares would inevitably end up being owned by those who believe that cutting it open yields more than waiting for the next egg. Apparently Newell isn't prone to cutting up the goose.

In terms of "a typical 3d app writes directly to the API", they really shouldn't.

The fundamental shift between DX12/Vk and the earlier APIs is that the old graphics APIs were fundamentally about graphics, in the sense that they described a specific way to draw graphics, and then in conjunction with hardware translated that into something that ran well. Originally, there were many very different ways this was done. Over time the hardware implementations all converged towards a common form, and game developers found themselves not really coding against the old APIs as designed, but twisting it's use into something that translated into what they wanted on the actual hardware. (That they knew and understood because of the consoles that just let the devs target the same or very similar hardware directly without a translation layer on top of it.)

DX12/Vk then approaches the API design from a completely different perspective: They are designed to provide an efficient interface to the functionality that is available in hardware. Much of this is graphics-specific, simply because the hardware is meant to run graphics, but in a very real way the API isn't about the graphics, it's about the hardware. Vk doesn't have the kind of simple graphics pipeline that OpenGL devs are used to, because it's outside the context of the API. You, the developer, are supposed to make your own pipeline, out of the pieces of hardware-supported operations that the API exposes.

Which brings this back to my point: The typical game dev has no interest or need to learn DX12/Vk, because they fundamentally do not provide what the devs need or want. Instead, game devs should largely build their work on top of an actual graphics pipeline. Right now, most devs get that pipeline out of the large 3rd-party game engines (UE, Unity), but if you are not using those, OpenGL or DX11 is not a bad choice, and a lot of studios still do that, and probably will for a very long time yet.

Hopefully over time someone will design a good separate graphics pipeline that runs on DX12/Vk, that is designed purely to be a good abstraction for graphics, and will do that well enough that it will replace most use of the old APIs. However, this will take a very long time, simply because of the human factors. (I already know DX11/OGL, why would I learn something new?) But even when it does, D3D/OpenGL will not be replaced by DX12/Vk, they will be replaced by a new translation layer that sits on top of it and is an analogue of these translation layers being built now.