I concur with your statement of "I don't like cursors so I don't use them". It is an empty and unsupported posit.  It is my understanding that if your procedure code is not running fast (which by the way is a relative term) due to alleged cursor code, then perhaps the database server’s RDBMS is not getting the horsepower it needs like memory, larger hard-disk, or a stronger processor.

There are cost-benefit trade-offs all over the place.  If a developer is cursor-centric in his procedure creations but said procedures do not perform “fast-enough”, what is “fast-enough” ?  Sure, a code review by another set of eyes might help point out some glaring in-efficiencies, but if “not fast-enough” means having to rewrite something at a cost that is less than cost of attaining more hardware, then so be it, attempt to reach that margin of diminishing return in terms of speed, rewrite your code. 

I liken the analogy to the number of people attempting to enter a very small automobile.  If you can only fit five persons but need to fit ten, are you going to cram five more persons or are you going to get a larger automobile?