Yeah, writing game engines can be a great framework for learning all kinds of useful and interesting concepts (and trying out experimental things!) but an actual, usable engine needs a ton of "boring" stuff regarding tooling and asset pipeline that hobby engines usually miss. When artist creates shiny visuals in <some editor> it is expected to look somewhat like that in engine and then you find yourself deep in some FBX/whatever SDK/your own loader + shaders wondering how the pipeline is supposed to work and how all the usual formats seem to suck in some way. Add animations, IK etc. and suddenly there is a lot of work to do that production quality engines solve.

That is not to say it is always needed though if the game is really simplistic. But there are a lot of engines capable of rendering instanced bouncing OBJs out there.

While in general you are right about the boring stuff (although some people find writing tools far from boring - e.g. me, i should actually write less tools if ever want to finish some of my own stuff:-P) the shiny visual bits aren't usually "just" imported. In the (commercial, not personal) engines i worked at, the artists used their 3D mesh editor of choice (max and maya) to make the meshes but only bothered with the basic texturing in that 3D mesh editor. The materials were created inside the engine's own editor since 3dsmax/maya's materials both do not make much sense to fully replicate and they lack functionality that the engine's own renderer (and material system) can provide.

In the last (commercial) engine i worked at, the pipeline was to export the mesh from the 3D mesh editor (3dsmax or maya) to a custom easy to parse format and then import it from the editor to a more compact faster and easier to work with format. Then the artists would create the materials and other resources that the engine needed to work with from inside the engine's own tools. The imported resource remembered the original file so that artists could simply export again and ask the editor to reimport stuff (at a later point we made the editor to automatically monitor the directories for changes - both Windows and Linux provide functionality for this - so the artists would simply export from their 3D mesh editor and the engine's editor would reimport the meshes automatically).

In the previous (commercial) engine i worked at, things were simpler in that we only supported 3ds max (although the 3dsmax SDK was far from simple, if it wasn't for SymbianOS it would be one of the worst SDKs i've worked with... but that is another story) and we exported animations and meshes directly to a custom format the engine expected. The exporter also had a "preview" feature to allow the artists preview the exported files in a standalone viewer that used the engine's renderer to make sure that things looked fine (in that case we actually did try to use 3ds max's materials, although in hindsight that was a mistake since even with the viewer the artists often assigned textures incorrectly - we should have relied only as little as necessary on 3ds max instead of making it the primary content editor).

The use of Orthodox C++ is more interesting than yet another game engine I think.

This speaks about language design and communities, approach to development practices.

Do features or concepts kicked around in the "hobbyist" engines ever influence or inform the mainstream engines?

These are features and concepts kicked around by mainstream engines. In fact, this work is inspired by Bitsquid/Stingray.