If that's what content creators want, isn't it in their right?
You're technically not allowed to download YouTube videos anyway, there just isn't a convenient measure against it. You're not paying, you're probably blocking ads and now you want to download stuff for free? You're worthless to creators.
Also, you're not getting to see all the videos that aren't on Youtube exactly because there is no DRM.
If <whatever language> makes certain assumptions and guarantees on behavior, then no, belief is not enough. It has to be plausible. GC alone really is a big issue and all the research (of which there is a lot) has not solved fundamental issues.
There are of course languages (like Rust) that have the fundamentals to match C/C++, but then it's still a matter of adoption. C++ also still develops.
Maybe on a Hotspot VM with JIT, while using frivolous amounts of memory for good GC performance.
You're not allowed to do JIT on consoles or mobile and you're memory constrained. A PC-only game engine is going to be a tough sell these days.
Also, unless you're bundling a JVM (not sure about the legals here) you have to make your Windows (i.e. primary) customers install the obnoxious Oracle Java runtime.
First of all, I'm talking about game engines, not games. Both Unity and the earlier Unreal Engine (afaik) used GC-ed languages for scripting.
However, if you want to make a quality game, you can not afford long GC pauses. I know that lots of people make games with GC pauses in them anyway. It is a value judgement, for sure.
It's certainly possible to work around GC pauses, but that effectively means you are manually managing your memory manager (instead of the memory), which can be surprisingly difficult.
It's also possible that whatever you do is so "small" that GC pauses never affect you. Enjoy your free lunch then.
Game developers used Assembly to write games when it was the best tool for the job. They then moved to C when it was feasible and then to C++ when that was feasible. For their engines, they never moved on to anything else, because there still is no better tool for the job, all things (tooling, SDKs, platform support) considered.
Unity, Unreal Engine and CryEngine are all written in C/C++. They have sometimes elaborate script bindings, but the engine remains in C/C++.
There's a lot of people leaving college that have never learned how to use C/C++ and immediately they want something they're comfortable with, which is Java/C# or Javascript or maybe even Python. These languages are not good choices for a game engine, for the reasons I mentioned. Will there never be a better language? I did not say that, but it would be an uphill battle.
There's two big hindrances for success right off the bat:
1. Refusing to just use C/C++
2. Attempting to support most of the platforms
Both problems compound each other.
All platforms (even Android at this point) have C APIs for everything you need. Creating another layer of abstraction here causes more work and overhead.
Trying to get Java running on iOS with 3D APIs is a huge task in and of itself. The same goes for C# (a task which Unity does for you). Languages that require JIT for performance don't work on mobile (unless supplied by the OS, e.g. JavaScriptCore). Debugging becomes extra-difficult.
C/C++ are not convenient to use, but not hard to use either. It causes discomfort at first, but you get used to it. Being forced to do memory management manually also helps with learning how to structure programs, with a bonus of not having to wrestle GC pauses.
Having said all that, using a commercial engine is totally fine, of course.