>>717319654
Agreed on the making games front. The classic fumble is for an engine dev to create an engine instead of a game, which typically leads to a lackluster engine at the end(since it solves for nothing) and no game.
Per re-implementing the wheel, I see it more as understanding arithmetic before trying to tackle algebra. Vectors and screen space vs. world space are a great example since, using a game framework, you typically have to come up with your own "camera" solution and by doing so will become intimately familiar with composing vectors like it's second nature which is going to help with comprehending 3D transforms and making shaders later, which engines only sort-of abstract away with tools like gizmos and shader graph(until you have to interpolate an object in 3D space). So, it's more about building up yourself then it is about just having the artifact.
An analog to programming education would be how a student is asked to re-implement lisp functions with a sub-set of a language or create computers from the ground up with projects like NAND2Tetris, except with engine dev the artifact isn't a 'toy' and can be used for future work.

For my personal experience, I've made over ten games with Godot and I like the engine, but I've never been able to 'hold onto' a project for longer then two months and I'm currently testing if making a custom engine that I can carry with me will make me more invested in finishing longer games.
Even if I fail, I've learned a lot about how lightning systems work and what I want out of editor tooling by rolling my own(Godot actually proves itself for this by the editor being implemented in Godot), so I can just take those lessons back to a General engine and possibly even modify that for my own needs.
Regardless, I think it's always important that new developers at least KNOW making a custom engine doesn't require you to go so low as learning a graphics API like OpenGL and have that as an alternative.
>Spoiler
I like interaction