What you are saying is mostly right, perhaps somewhat of an oversimplification. Interestingly, these days I work with quite a bit of Clojure.

Most of what I've been describing came about because people were in OOP hell, and decided to move towards composition vs. inheritance. As multi-core machines, GPUs, and more sophisticated games arose as well, there was more of a need to start thinking more in terms of what the CPU wants and pipelining things for the CPU, GPU, and such (think PS3 for instance). To some degree, this thinking was always there and circling back to 80s game programming, but a lot of people got off-track. For example, memory allocation was always a thing to the point where no sane person every used anything in C++ from std because of allocations and bad memory layouts. Structure packing has always been a thing of course too. Another was thinking about v-tables and how they just get in the way, especially when working on more limited platforms like the NES, 286, etc. in those days.

Games are mostly about enumerating a lot of stuff, very fast, per some measure of time, and then repeating. If this sounds a bit like a map or a reduce in functional terms, it should because it is. You have loops inside loops, and you try to operate on similar blocks of data, rather than jumping around all over the code or iterating mixed collections (or hybrids using co/contravariance). It turns out computers, especially x86, really like it when you enumerate things in a line. There's a fun presentation somewhere where Stroustrup himself shows how an array can be faster in many situations than a linked list when the linked list fits the exact description of the correct data structure.

Anyway, you can rig a lot of this into Java as you say, but fighting the GC is still considerably hard. Clojure itself is even worse because it generates garbage like nuts and you also end up doing things like transient! or using volatile! to work around other speed issues. I'm not sure about Kotlin would be, but as a JVM language dealing with JVMisms, I suspect largely the same as Java. Other languages that are more predictable or not GC'd fair much better for games, they are just not used as much because of the people in the industry, technical debt, tool chains, know-how, risk, etc.

Where I'd disagree with what you said is that those constructs are all you need. For certain parts of your game you still need quite sophisticated stuff. Threading primitives and complex pieces of code help that are a pain to write with just what you described. But these things are generally higher level. For example, scripting engines are a good thing to have and often not written in the same language (ex: lua). Editors are another example. They aren't part of your game directly necessarily, but these days they increasingly are on some level, at least some form of them. Either way, you benefit from building toolchains in a variety of languages to help a game. It's not just a single code-base and ultimately you only have so much time, so you take shortcuts like throwing in Lua to make life easier.

Regarding SDL2, it's probably great for what you are doing. It's more low-level, but if you want to build things from the ground up, it's a fine and well-tested choice. There are other alternatives, but mostly in the form of full game engines. Certainly you could do this with something like Unity and it'd be good enough. If you're going 2D, the one piece of advice I'd give you is I'd say probably these days you can get just as much done by making things 3D and fixing the camera most of the time, or using a hybrid. 2D is more difficult than people think and often sucks in certain engines (ex: Unity :) ). Anyway, it's just a matter of some head banging and time. If you go SDL, you'll learn a lot, just remember, build games, not game engines.