You haven't seen good MVC architectures, then. The ideas behind MVC are very simple:

• Every thing that happens has one and only one place in the code that does it.
• Every piece of code is broken up into functional areas. You generally have
  • Formatting and layout (aka, View)
  • Business-related code (aka, Model)
  • Datastorage code (DBI-related stuff, generally)
  • The glue code that actually runs the stuff (aka, Controller)

Your complaint about having to wander templates has to do more with how bugs are reported. Generally, the user says "Screen XYZ is doing foo when it should be doing bar". So, the debugging generally goes something like:

1. Look at the tepmlating for screen XYZ. Is it not displaying the right stuff?
2. Look at the engine routine that makes the data for screen XYZ. Is it not calling the right business objects?
3. Look at the various business objects called for screen XYZ. Are they doing the right thing(s)?
4. Look at the datastorage behind screen XYZ. Is it storing the right stuff in the right way?

So far, you're still doing the same amount of work. In fact, you might even be doing more than you would in a more naively-architected system, because you have to open more files and follow through more subroutines. And, I suspect, this is where you're stuck at.

That's because you don't see the point behind MVC. MVC adds some complexity to the architecture of a system. But, it does so in order to reduce complexity at another stage. Once you fix something in MVC, it stays fixed all across the entire application. Period.

And, there's another point behind MVC - people with different skills can collaborate on the same project. Most web applications require that everyone know language X. MVC-architected applications require that

• the layout guys know HTML, CSS, and the templating language
• the coding guys know language X
• the datastorage guys know SQL and a little bit of language X

So, now, the coding guys don't have to know CSS. Wow, is that a relief!