I like refactoring. Realy. Who doesn't ;)? But there is a downside:
1. Time spend on writing/testing it.
2. Loose of encapsulation. Too deep rewriting lead us to extra work later.
And you should always estimate all pros and cons before you begin to code.
Do the author of the article realy do better? I'dont think so:
1. From the perspective of execution speed this view (IMO) doesn't need any rewriting - it's fast enough (0.7s is suitable for reporting). Or am I miss anything?
2. Original sql-script is rather clear, it refer to two entities only. Resulting one contains constants and refer to 11 tables. What happend when the application logic will be changed? We will have extra work.
I think, that it's normal to reuse existing db-objects. Of course, you should control the nesting level of usings and break too long chains. But some layers of abstraction help.
I agree that only needed columns shoud be included in the result view. And it will be more than enough (IMO) in this case.