It's still being used for some pretty mainstream Indie games, like just-released Streets of Rage 4, Flinthook, Celeste, Bastion, Fez, Axiom Verge, Stardew Valley, TowerFall, etc.
Doesn't have all the mess or constantly moving target that everything else has, either. I mean it changed so little from XNA 4 that I could easily port a game designed for Xbox 360 over to it (shaders and storage took some extra time).
As a hobbyist game dev I'm looking at moving to a multi-platform 2D game engine (last few games were done for the web using Phaser). The two engines that seem interesting are Monogame and Godot. My limited understanding is that you get more tooling and ready-made things with Godot compared to Monogame. I'll have to do another deep dive of these two engines soon.
Monogame has the advantage that it has been used for commercial games, so you can get a good feel of what it can handle. Most of what I've seen showcased from Godot are more toy games, not really commercial. Now granted someone has to be the first to do it on Godot, but part of the reason you don't see it might be because it has some limitations you'll run into (but probably won't as a hobbyist developer).
XNA also had a really large community at the time, and a lot of questions you have with Monogame, if you can't find the answer noromally, you can just look up the answers to for XNA and it will be the same answer, so there's a good amount of history to reference there as well.
The important thing is just to pick something and start. After XNA died out, there was several years where I didn't make any progress because I kept going back and forth on what platform or tools I should use. I do recommend picking something open source and free, though, because I've had games get stuck on old proprietary platforms in the past and have had to port them to other platforms (i.e. Flash, Cocos2d iOS).
I also like that you actually have near full control of what is happening, rather than poking at a black box engine and hoping the bits you plug into it work correctly. Of course, I'm of the age where you had to write your own Windows message loop and wrangle OpenGL or DirectX yourself to do much of anything.
Does it support 3D? I don't remember whether that was the case back then.
Edit: There's a 3D game right on its home page :)
I'm surprised at the idea that Unreal is inaccessible though. Especially as an indie, UE4's blueprint system will do absolutely anything you need to do. And, for extending the editor itself, Python is available.
I've switched from Unity ~7 months ago and never looked back.
It looks like that they're re-working GDScript for 4.0, so that'll get a lot better, too.
Does it make sense to hold off diving into Godot until 4.0 (for 2D-based things) or will there not be too much to "relearn"?
Therefore, I assume that the fundamentals of Godot will stay the same and you should be fine diving in with 3.0 already :-)
Unity's C# scripts on the other hand - despite all of the engine's problems - are incredibly straightforward to write, set up tooling for, build, plug into a project, and you can use them to control everything from game logic to the editor to the rendering pipeline. This is Unity's greatest strength, IMO.
I wouldn't do networking in blueprints. But for your core gameplay ? It can absolutely do anything you want.
Blueprints provides the tooling to package stuff into re-usable components, exactly to avoid spaghetti code, just like in most graphical programming languages.
Unity keeps rebuilding the core foundation of the engine which means at any point the work you did could be invalidated. So now everyone's operating on a different version of the engine, trying to solve bugs related specifically to that version and it means if you actually need something from a later one you're SOL.
Whenever I've worked w/ Unity I've felt like I spend more of my time struggling with tooling than actually making a game. From a more skeptical point of view I understand why: It's because it means they can create a marketspace where you have to buy additional tools to make game creation more robust. From a developer point of view though, it results in a nightmare.
But in the end I got so frustrated with Unity that we did do the switch to Unreal. So far I actually had to do a lot less coding in Unreal than in Unity. There's almost nothing you can't do in blueprints.
The only thing I had to write C++ for is some JSON parsing because the existing JSON blueprint libraries (from the marketplace) are terribly slow. What little C++ I had to write is fairly simple. Just using core APIs form Unreal itself (FJsonObject). It's just creating structs and calling APIs. Easy enough even for me.
Everything else we implement in Blueprints. No C++ required.
I'd say a lot depends on how much stuff you're doing every frame. From what I've seen, Epic is emphasizing you should avoid running blueprints every tick, and instead use event-driven programming heavily (or "steal" ticks from input handling), and then flip appropriate switches to remove anything that doesn't need updating every frame from even being issued a tick by the engine.
This is by far the best it has ever been in my 25 years in the game business. If you are daunted by making a game in Unity or Unreal today, you would be without hope twenty years ago.
I understand the likely reason why he isn't, because he doesn't want to have people bugging him for support on it, but if I could sign a "I promise not to email you any questions about it and I'm using this at my own risk, pinky swear" and get access to download the latest version of it, I would.
Please correct me if I‘m completely off.
Unreal is just way too inaccessible, as an individual, non-C++-veteran (used it a bunch in college, but modern C++ looks nothing like what I've seen), non-games-industry-veteran. It's also fairly opinionated towards first person/third person action games.
And then Unity is of course a dumpster fire. It's much easier to get started and hack something together with, but you'll be hacking and fighting with the engine for the entire project.
Open-source libraries/engines exist, like Godot, but none of them properly support consoles because console APIs are apparently proprietary (??) because the console vendors are apparently stuck in backwards, draconian software practices from 2002.
The whole state of indie-accessible tooling is just deeply depressing.