The alternative is to paint the contents of the cell manually (that is without using UILabels and the such) using CoreGraphics.
Check out the drawContentView: method here: https://github.com/ferostar/fast-scrolling/blob/master/Class...
However I just finished an application with a UITableViewCell, defined in a nib, that had 3 labels and a image. The labels depend on the data that the row was displaying and the image was the same in every row (it was a custom disclosure image).
One of the table views that that used this cell had 100 rows and it loaded and scrolled without a hitch.
Most of the slowdowns people experience with scrolling is if they have transparent cells and/or they don't load lazy load images on a background thread.
I agree that if you've tried all sorts of optimizations and you are still experiencing slow scrolling then painting the contents manually will probably be faster but it is IMO more work then 99% of people need to do and, like naz said below, there can be accessibility issues.
When Loren Brichter wrote that 3 years ago it was a much bigger deal. The iPhone 3G was extremely underpowered compared to most of the devices people run iOS on today.
That said, if you get frame skips after all that then overriding drawRect for the content view is a great way to speed it up. You have to be careful to keep your app accessible though, since the view has no labels for the screen reader to read. And orientation changes can look awkward.