> it's hard to see those consequences at the outset due to the fact that Rails code is so easy to pick up and understand
Yes, there are tools in ActiveRecord that can help mitigate some of the performance issues, but as I noted above, it's extremely easy to overlook such tools until you are too far down stream to really do much about it. The symptoms of not using such features may not show up until much later when the number of records swells, and some code someone wrote 2 years ago starts slowing down the whole shebang simply because they used a select rather than a pluck. This is ESPECIALLY true in large corporate web app environments where the number of records is large and the number of people with their fingers in the code base is equally sizable. And good luck convincing management to go back and fix old ORM tech debt until the whole thing starts falling apart at the seams.
Hell, pluck didn't even exist until 2012 with the release of 3.2.1.
Might depend on the amount of spaghetti, but I've typically been able to retroactively fix bad AR patterns backwards compatibly, and get huge speedups. The only time it's a real issue is when an API endpoint is just returning way too much and you have a lot of clients depending on that API returning all that data.
What's a lot harder to deal with is AR callback hell, which can be very slow if you have enough nested callbacks, and can be really hard to fix without breaking everything. Using many AR callbacks is just a bad idea for a big app!
