>>>Cursors I truly believe can be avoided altogether.

An example of when a cursor is necessary: when interacting with a SQL-based API that encapsulates business logic (Microsoft Dynamics GP for example). Am I going to directly insert inventory adjustment transaction data into base tables in a set-based fashion? Not likely. Instead, I'll call the vendor's stored proc to insert a single transaction--even if I need to loop through a thousand source rows to call the procedure one at a time. (The benefits of encapsulation sometimes outweigh the performance and elegance of set-based operations.)

Another example would be complex recursive operations where the outcome is affected by earlier passes in the recursion (i.e. things that you can't do with a simple recursive CTE). Sometimes you do in fact need to walk through data a row at a time.

By all means, cursors should be avoided, set-based processing is the way to go, and for the vast majority of data operations you can avoid cursors. But I'd argue that cursors cannot always be avoided.

The same principle is true of indexed views. Yes, they duplicate data. Yes, they can often be avoided. Yes, they can be abused. But they are very helpful when used properly, and they can solve problems that you can't easily solve other ways.