While yes the Vulkan & OpenGL APIs are pure C, that's very, very little of what you actually code against. You very quickly abstract that or use a middleware like bgfx or whatever. In the case of Vulkan while the spec API is C, there's first-class C++ wrappers/bindings provided as well: https://github.com/KhronosGroup/Vulkan-Hpp
And other than Vulkan & OpenGL, you'll find that most other APIs/libraries in the space are C++, not C. Valve's libraries are C++. Dear ImGui is C++. Bullet & PhysX are C++. Microsoft's glTF SDK is C++. etc...
You can argue endlessly about how "true C++" those all are or if they're just "C with namespaces" but that's largely irrelevant - they aren't C and they need a C++ compiler.
I still have to read the full paper, thanks for the post!
Many people rant about C++, but, IMHO, overall, taking into account ecosystem, tools, etc. C++ stands as an almost unbeatable technology when you put everything together. The language has quirks, asymmetries and all of that. C++ lives the curse/blessing of C compatibility.
But since C++11 it is nicer to use and all the standards after it have been improving on it: generic lambdas, move semantics, structured bindings, string non-template parameters, constexpr and consteval, decltype, auto, concepts... and now the C/C++ ISO committees seem to be more coordinated: seems they are proposing subsets like attributes, lambdas or nullptr into C, directly, and bool and others. It is amazing what you can do with C++ that is difficult or almost impossible to do with other languages, and you have basically all C interfaces available, which are the base of so many libraries since C is basically how you interface native code from almost everywhere.
On the missing pieces I would mention that you need to use macros to have some kind of reflection for members and pattern matching and networking would be really nice to have. Also, resource embedding could be better (#embed and std::embed seem to be trying to solve this). Also, user-defined attributes for things such as struct MyType { [[serializable]] int myInt; ... } would be really nice and it works well in languages such as C#, Java and D.
Modules are still an experiment implementation-wise, but hey, they will improve on the side of hiding implementation details by a big margin and have a lot of potential.
As for the ecosystem, nowadays you have CMake (whose language sucks badly) and Meson (which I personally love). Together with Conan package management things have improved a lot since I started coding in around 2001.
Pack that with an IDE like CLion or Visual Studio + Resharper or lightweight IDE (Emacs + Lsp and the like) and you have an environment that is very competitive and whose code can be compiled almost anywhere. From ARM to x86, MIPS and even Webassembly.
That is why I think C++ is still the way to go if what you want is performance: you also have interfaces such as OpenCL/GL/Vulkan/SIMD libraries (though not C++ standard) where you can access hardware. Also, vendors and open source have things such as https://github.com/cginternals/glbinding or https://github.com/KhronosGroup/Vulkan-Hpp which help quite a bit and always oriented towards C++. It seems that C++ is becoming the natural child of C for inheriting graphics programming and some of the embedded area, though C is still king there. Or look at https://github.com/VcDevel/std-simd to access SIMD.
If you want GUIs, same, you have at least (but not only) Qt or WxWidgets.
Want to interface scripting? Pybind11, Boost.Python, WrenBind17 for Wren, Sol2 for Lua... and all things that interface to C work also if you feel brave...
I really think that when it is about getting the job done... C++ goes a long way towards the task.
This is my 20 year experience of C++, almost 13 of those years professionally. Now, back to read the paper. :)
My problem is I don't know much C#, but it really confuses me why Epic decided to use C# for the framework of a C++ engine...
That project is on hold while I play with vulkan directly via https://github.com/KhronosGroup/Vulkan-Hpp.
I have too many projects.
Vulkan is basically a C API, defined at https://www.khronos.org/registry/vulkan/
There is a C++ wrapper, originally designed by NVidia, https://github.com/KhronosGroup/Vulkan-Hpp, but it isn't part of the specification as such.
Likewise the shading languages are either GLSL or HLSL, although in theory others could be created for SPIR-V.
Of course, Vulkan has the benefit of GNU/Linux, Desktop Windows (not on UWP) and about 14% Android devices (optional in 7+ versions), but middleware engines make it kind of irrelevant.