For those of us who code in web-land, a delay of one hour would be appalling, let alone an entire week. (And of course even then, it relies on user action, and so will never be 100%.)
Step 1, Notice bug
Step 2, Fix bug
Step 3, Deploy bugfix
The steps between 1 and 2 could obviously take a variable amount of time, but Step 3 is 'near instantaneous' on the web. The thought of having to relinquish deployment to somebody else, and that somebody else possibly taking a week to just alert users that there IS a bug fix, much less the time it takes for those users to see and apply the fix, that's a relative eternity.
Maybe I'm a little biased on this, but I hate that a web app I might be relying on can change completely (both in GUI and functionality) without my consent or involvement; at least with app updates I can get some warning and release notes -- a chance to extract my data before taking the plunge... but I guess I'm getting a bit off-topic.
It is offtopic, but still interesting. One supposes that is the reason why apps cost a set amount of money (usually) while web apps are usually a subscription model. That is of course questionable when the app uses web views to your server, as those customers always cost you money so long as they're using the app vs. standalone apps (like games and the like) where you truly are making a one-time purchase.
It's yet another area where the nature of software and the networked world breaks our object-oriented intuitions in ways we're still trying to resolve in the social contract.
You've exchanged money for a good, and as the app owner there aren't any readily available means of getting the good back from the owner should you disapprove of how they're using it, just like it would be with a tangible good. Obviously copyright still stays in effect so their ability to copy, resell, yadda yadda are still restricted, but otherwise it's theirs.
That said, in this day and age, fewer and fewer apps are completely self-contained, and/or work without being plugged in to something, so it's effectively a moot point.
At the same time, I understand your feelings about wanting to be in control of updates. (As a user, I'm even upset that Apple doesn't allow the user to roll back.) But when devs can count on every user being up to date, it enables them to push new features more quickly instead of having to write backwards compatibility, fallbacks, etc.
The question of who owns and controls code is a sticky one, and I'm not sure there's an ideal answer; to the extent that there is, I think it varies highly by the nature of the app.