Having written a fair bit of MEL myself, I feel qualified to say… it isn’t actually a good thing! Yes, making macros easily is good for artists, but I would argue that any situation where an artist needs to make a macro should have been solved with an addon, operator, or tool. Thus, macros are band-aids over deeper issues. Furthermore, the structure of the language, MEL, lends itself well to making macros, but not… not to actually programming. Putting aside the esoteric syntax, the design of the language is entirely procedural. I don’t mean procedural in the sense of precedural generation, no, I mean procedural as in USER: GIVES COMMAND – MACHINE: DOES THING. Everything is done this way, side-effects galore. It’s not easy to write code in a generic, reusable way when the order of commands matters, and context doesn’t. It’s especially difficult when, by making commands, the data you are working on can change. New data can be created. Connections can be made and broken between nodes and now you have to find things all over again.
Let’s contrast this with Blender’s Python API: There are two methods of working, bpy.ops which is similar to MEL’s procedural approach. It’s commonly used for creating macros, but it’s not used much in addons for… essentially the same reasons I outlined above. Then there’s bpy.data – where the programmer doesn’t give commands, but rather declares what the data shall be- object.property = value. Sure, MEL has setAttr, yes, but it’s limited in its usefulness because you can’t, for example, node.connection[0] = other_node, while it is possible to do something like that in bpy.data. It’s easy to write clean code in Blender with bpy.data, because once you’ve gotten the important information out of the context, you can do things in just about any order and set the values of properties however you wish.
It’s a bit hard to explain without pointing to more specific examples. The point is, MEL makes creating macros easier for non-technical artists at the expense of technical artists. That isn’t a good trait for a programming language. Blender isn’t always easy for non-technical artists, so maybe there’s something we can do to improve the existing API to extend bpy.ops to make it even better for making macros. Then, we can have the best of both!
Anyhow, I went somewhat off-topic with this, but I didn’t start the off-topic tangent!
EDIT: before anyone says anything, I know that there are other ways of accessing Maya that are more object-oriented… but we don’t want five APIs in Blender, then it will be as hard to maintian as Maya is. Yes, five: MEL, Python (Mel Wrapper), PyMel, C++, Python (OpenMaya). Really. Five APIs. 