The article you linked to is advice from people who port games to Linux on how to make games more portable. It's not advice on how to ship them on time, how to make them performant, how to minimize the amount of developer labor required to build them. Given what a small share of the market Linux is for games, developers have other priorities than what makes games easy to port to Linux. And it's not a chicken-and-egg problem; the Linux market for games isn't much smaller than the Linux market for any other commercial software.
Performance is orthogonal issue to portability. You can make it portable, and perform well too (using something like Vulkan and proper engine design).
Linux gaming market is growing. Not sure about other commercial software in this context, but I'd guess it can indirectly be affected too, since bigger gaming market makes Linux desktop usage grow in general.
So, "Here, use a different API with worse developer support, and in return you get access to a market that's ~1-2% the size of the Windows gaming market?"
I mean, I'm all for OpenGL. I use OpenGL. Hell, I develop OpenGL games on Linux and then port them to Windows afterwards (released ~10 made that way so far). But the choice to use it depends on what market you're going after.
Vulkan has better performance than DX11, and it has literally twice the audience of DX12 - DX12 only supports Windows 10, so any W7/W8/etc users are SOL unless you use DX11 or Vulkan.
My point was, adoption in engines is relatively slow, but once it happens, things become easier. So current usage lists aren't a reflection of general progress. Unity for example gained Vulkan support in the latest version which came out recently, and Unreal is still not there (but already close). Same goes for Lumberyard.
Of course the tax on development imposed by lock-in freaks translates into that slowness. I.e. as you said, need for engines to support many balkanized APIs means slower releases to the market.
In the abstract, performance may be unrelated to portability. But if tooling, drivers and expertise are all focused on DirectX, and if getting OpenGL to do everything DirectX can do requires using vendor-specific additions to the spec that are non-portable, then in practice, it may be harder to make OpenGL performant across multiple vendor's GPUs.
