big difference is teams. If you're fine working by yourself, then an engine where you have 100% knowledge scope is great.
The moment you introduce another dev or artist or any individual that needs source access to work on your game, you'll probably have them hitting every pain point mentioned in the article and more. Why's your UI buggy (or does it even exist?), why's rendering this thing slow? So time is spent teaching them (and there's likely zero help on the internet unlike Unity/Unreal), or making tools/bugfixes to accomadate for them. i.e. less time on the actual game.
Hence the mantra: make games, not engines. If you like making engines, that's a good reason in and of itself to ignore that mantra. But if your goal is to make a game, then you shouldn't have to worry about the nitty gritty until it needs to be addressed.
The moment you introduce another dev or artist or any individual that needs source access to work on your game, you'll probably have them hitting every pain point mentioned in the article and more. Why's your UI buggy (or does it even exist?), why's rendering this thing slow? So time is spent teaching them (and there's likely zero help on the internet unlike Unity/Unreal), or making tools/bugfixes to accomadate for them. i.e. less time on the actual game.
Hence the mantra: make games, not engines. If you like making engines, that's a good reason in and of itself to ignore that mantra. But if your goal is to make a game, then you shouldn't have to worry about the nitty gritty until it needs to be addressed.