Not an afterthought, but I'm more interested in providing features for my customers. The site is fast enough, and the time to develop new features is more important than making the thing scale for zillions of users when I only have 100's hitting the web site.
I don't ignore performance, but if you're charging enough, it's certainly not the primary consideration.
Ideally, in the Rails world, the people building client apps would only have to worry about the algorithmic complexity of their code, and the libraries should be operating efficiently under the covers. To that end, you're completely right in that you shouldn't have to worry about performance - the people writing the software you build on should have already have done that. But when they don't, that costs you time and money, and I think that's a shame.
The same concept applies to gems. You just construct a scenario that stresses your gem internals, run it with ruby-prof, pop open the resulting dump in kcachegrind or similar, and explore to find the hotspots. I did something like this for MongoMapper, and documented the process here: https://www.coffeepowered.net/2013/07/29/mongomapper-perform...