Combining views, nesting views, and taking large, large data sets without filtering through views, are very common code smells that inevitably lead to trouble. Because views act like tables within the T-SQL code, people tend to think of them as if they are tables. They're not. With the exception of an indexed view (which, is a table, just a fancy one), views do not store data. They have to go to the tables for that data every time. Also, the optimizer has to deal with the execution plan creation and management and all the rest. A very large view combined with a very large view is not the same as one table joined to another. You're literally multiplying the work done by the engine.
The single biggest problem with T-SQL is that it doesn't lend itself well to code reuse. Almost every mechanism people use to avoid writing the same T-SQL two times, views, functions, actually can lead to problems. It's painful for people to hear, but I usually suggest writing a query twice (or six times) if you can adjust it to fit each of the two (or six) situations rather than slap it into a view. It goes against the grain (code reuse is a vital part of development), but that's just how SQL Server works (and Oracle, and MySQL and PostgreSQL (although a little less than the others in this regard), and...).