And can anybody give me firm examples as to why "mixing biz logic in the view can lead to all sorts of problems down the road."? We all "know" it's bad design, but why exactly?
It really all comes down to isolating changes. If something needs to be modified, how much of your program will you have to alter? I can give you a real-world example that I ran into with a colleague.
He had created a 50+ page application driven by a relational database on the back-end. The code for interacting with the database and processing query results was directly mixed in with the presentation logic. One day, he was asked to change the application's storage system from a relational database to Berkeley DB. He ended up having to nearly rewrite the entire system since his database code (and other related elements) was scattered around everywhere instead of being confined to one or two source-code files.
This scenario is common to many applications, both large and small. Small snippets of business code are used repeatedly in several places by presentation code. Any dependencies on how that business code actually does its job are going to spell trouble should you need to change things.
It's like going to McDonalds. Do you care about the details of how they actually prepare their burgers? Generally not -- you just care about the result. By not being dependent on their internal processes, they are free to change their ways without upsetting you. Same thing applies to programming ..... or any engineering for that matter.