For example, you use a library which gives you 99% of functionalities you want. Now there's a 1% use case you want different behaviour and you can't directly modify library code. There's an escape hatch here, it's Ruby. It's like "fork" on steroid.
Why Rails ? Because it's the "only" web framework in Ruby. No second choice for large scale application.
from a cost perspective, again I'm not super experienced in rails but enough to debug production issues and ensure stuff works -
I recall that for this one rails application, there were like 30 instances of it running on some beefy configurations and it was getting hammered quite a bit. We saw it was only able to manage like 300 req/second. A lot of time was spent rendering the template, like a few ms.
I ported that thing to Go and it takes microseconds to render a template. A single Go application running on cheap, shared configuration can handle like 10x the traffic.
Less code >> more performant in general use case.
TL;DR is: Vendor lock in vs performance lock in. It's hard to not have both at once.
I still am not convinced to use rails over Go for my needs, but I am glad you helped me get some more insight.
A second issue is that if you come from a background where everything is either explicit or obvious, you are in for a world of hurt. I've seen senior developers try to figure out where a particular method is defined by setting a breakpoint, connecting a REPL, then invoking some special methods to get Ruby to tell them the file and line for the source definition.
It is just a different way of developing, and (personally) I think the reputation is a bit cult-ish.