Nice, that's pretty good. I think you've got it. It's not an absolute prohibition, its really just separating out the different functionality. So your controller is supposed to pass stuff off to the model, but you may get lazy and just skip the controller and do it in the controller.
One main benefit is the ability to reuse your model functions. Nearly all of my classes are singletons and the functions are static so if I want to expand the web app that is RMU, I can chuck in a few lines and have a like system up, comments, deal with permissions, all super quickly across any different component I want to go and write.
Web is a wee bit different, definitely simpler. I'll explain how a page like a script works eg
http://www.gdunlimited.net/scripts/rpg-maker-vx-ace/misc-system/splash-screen-map
This is specific to this site but quite common. The "scripts" part of the URL triggers the scripts controller to run. My URLs are pretty cool, and I've got a special router system that allows me to exclude ID's, so its not so clear from this URL, but from my controller I'm calling a specific function. "rpg-maker-vx-ace", "misc-system" and "splash-screen-map" are variables that go into the function and are sent to the model.
In the model I convert these to numbers:
rpg-maker-vx-ace = engine_id
misc-system = category_id
splash-screen-map = string
And using these 3 variables, I use the model to query the database to bring back the information relating to the script.
So in the controller you'd be all
$script_data = ScriptsModel::getScript($engine_id,$cat_id,$seo_title);
And you'd come back with an array of data.
Then you simple pass this onto your view, where all the HTML is. The view ONLY contains html (even though you gotta plug your vars in, I use a templating system so technically...)
So in the view you have something like this
<h1>{$script_data["title"]}</h1>
And that's the end result. So you can see how each part plays its own role, and the controller is only like a traffic operator, receiving and sending variables.