ZDoom

If they fail, one will crash the game in the middle of a level, the other won't even start up.

The far bigger risk is something else: Badly written code constantly creating new textures without stopping.
All things considered, it's not a good idea to give modders control over limited hardware resources. These can result in nasty performance regressions and other things and are very hard to diagnose.

I am not as familiar with the engine internals as others are... But I don't understand the difference between a mod author defining 5000 (or whatever random large-ish number) ANIMDEFS entries and using those versus creating the texture via code.

How do those two approaches (that call the same underlying engine functions to create the textures) affect the engine differently?

It was a deliberate design decision to not give a function like that. The canvas texture is allocated on the GPU and for that reason need strict resource control. Allowing zscript to create arbitrary textures with unknown lifetimes will create tons of problems for the engine. On top of that ZScript is garbage collected, making it even more tricky to know when such a canvas is no longer in use.

Requesting the ability to define canvas textures via ZScript instead of being limited to ANIMDEFS-defined values.

Maybe a new function under the Canvas class and lifting the code from ParseCameraTexture?
native static Canvas Create(String canvasname, int width, int height, int offsetx = 0, int offsety = 0, int usetype = TexMan.Type_Wall);