Hi, one of the GZDoom developers here. Thought I'd clear the air on something, before the comments go out of control. I've spoken to Marc about this on Discord before, so I think he already knows this, and this comment is more directed towards the general populace.
First and foremost, it was a quickly-hacked-in development CVar. Originally meant to to debug things like interpolation, particularly with models and tween-frame player movement. If you're a mod developer, I'm sure you've run into a lot of situations where you'd be thinking, "hey I wonder if I could add this one stupid thing as a test" and you spend 5 - 10 minutes quickly putting it in, with no intention to expose your players to it because you just wanted to internally test something and want to add it in in the quickest way possible, without caring if it'll break something else. This is exactly the situation here.
And as a result of this, the problems with i_timescale becomes obvious: instead of "properly" adjusting the timescale of things, the ENTIRE engine gets adjusted - if you activate slowmo, suddenly trying to open the console will also be slow. Movement input will be polled slower. And a whole other bunch of weird stuff. This is the direct result of precisely not much time being spent into adding the "feature" - that's because it's not a feature. It's a debug command to aid engine development.
Oh and BTW, a quick history lesson: technically it's existed in ZDoom for a very long time. Before the timer refactor, ZDoom had a command-line option (it was called -timerdelay) where you specified the number of ms per tic. A value of 1 made for really fast games, and a value of something like 200 would be really slow. The value 28 was ZDoom's "approximate" default.
So in other words, it was something that already sort of has code for it lying around, and it was quickly repurposed to do another thing, with little thought into actually making it a usable feature.
So what's stopping it from becoming an actual, usable feature for mods? Nothing really... it just needs someone to actually step up to dedicate their time to code it properly. Unfortunately, it's not something that can be done in 10 minutes. A lot of care (and work, obviously) needs to be taken to properly support this as a modding feature.
On top of that, arguably some people (other developers) think that the REAL way to add slowmo to your game is not via messing with the entire engine's timescale, but have actors be able to individually tic at varying rates. Needless to say, again, this isn't something that can easily be added.
If someone comes in and does it nice and clean, then sure, I don't see why it can't be an official modding feature.
So, no, it's not "GZDoom developers gatekeeping wah wah". It's just that it's not easy to add proper support for it. Remember that GZDoom is a collaborative work by several people out of their own free time, none of us are getting paid to do this stuff. If something is easy to add, then sure, we can add it. But something like timescale adjustment certainly isn't easy to add.
tl;dr it's not easy to add proper support for this in the engine
That said, Marc's put out a cool mod here and I personally have actually also used similar techniques for the purposes of video recording. Use it as you will. Just understand the true circumstances of what goes behind engine development.