you were either burned really hard by metaprogramming gone wrong or you've actually never seen it done properly.
there is a school of thought that says in some cases you should not shoehorn the problem you are trying to solve into <insert your favorite programming language in here>. In cases like that having a DSL (which does stand for Domain Specific Language) is worth its weight in gold. Focusing on expressing the problem in it's own domain language is beautiful. Ruby just happens to be awesome at building DSLs.
to your point about "elegant" messes: you can create a mess whatever tool/language you want. the language is not there as guardrails. I agree with you that less is more and in most cases you don't need some of the uberpowerful features, but when you do, the way you solve the problem is absolutely beautiful.
IMHO, Ruby code is the closest to code poetry that you can get with a vanilla/for the masses programming language.
I've seen it done properly, it's just that the majority of the Ruby metaprogramming I've seen is completely unnecessary. I'm sure it's God Mode to a lot of people, and the powers of God are difficult to resist.
DSLs can be great. The problem I have with DSLs in the Ruby world is that it's too normal to just whip up a DSL for things that don't require it. A good example of a DSL is RSpec, which has a very specific goal in mind and is well documented. A bad example of a DSL is one that Bob the developer created for a Rails app at Acme Corp., which is sparsely documented because Bob is a busy guy and there's a lot of tasks in the backlog more important to stakeholders than documentation. Said Rails app at the end of the day serves webpages, and somehow the business logic "required" its own language built by one or two people who couldn't dedicate enough time and thought to the design of the DSL; it was built pragmatically, and down the road when Bob quits nobody is going to want to touch it because the methods defined in the DSL have their tentacles in everything. In the best case, Bob actually wrote tests just for the DSL as well as the business application itself.
You are right in that a mass can be made using any tool. Where I disagree is where a language can act as guardrails. Guardrails might not even be the right term. What I do believe is that, a great deal of the time, the most powerful tool isn't necessarily better than the simpler one. Someone learning to fly probably shouldn't be given a fifth-generation fighter jet, as a much smaller aircraft would allow them to fly sufficiently without the complexities I'm sure there are in operating a military fighter jet, despite the fact that the fighter jet can do "more". Even an experienced aviator probably doesn't need to be flying a fighter jet for their purposes.
Ruby, IMO, is a lot like a fighter jet. Yes, it can fly from A to B, but it's can evade radar, has a machine gun, and do maneuvers other planes can't. Other languages might not have those other things, but that prevents less disciplined pilots from the temptation of doing unnecessary things that can result in mistakes. Sometimes you need a fighter jet, but most of the time we're not at war.
Everyone's experience is different, and I'm not saying your point of view is invalid, but I just feel different personally. I really wish people wouldn't use Ruby like they're a fighter jet pilot all the time. As someone who attended a coding bootcamp, I would like for bootcamps to emphasize hesitance around writing DSLs and metaprogramming rather than pushing those concepts on to junior developers as if they are the duct tape that applies to all problems.
there is a school of thought that says in some cases you should not shoehorn the problem you are trying to solve into <insert your favorite programming language in here>. In cases like that having a DSL (which does stand for Domain Specific Language) is worth its weight in gold. Focusing on expressing the problem in it's own domain language is beautiful. Ruby just happens to be awesome at building DSLs.
to your point about "elegant" messes: you can create a mess whatever tool/language you want. the language is not there as guardrails. I agree with you that less is more and in most cases you don't need some of the uberpowerful features, but when you do, the way you solve the problem is absolutely beautiful. IMHO, Ruby code is the closest to code poetry that you can get with a vanilla/for the masses programming language.