My mid-1990's employer had a solution for the installer dilema.
All of our VB programs, com objects and assets were loaded into a MS SQL database table. When our generic launcher program started it would query the database, figure out what app the customer had purchased and downloaded the necessary objects (if the cache was stale). If we accidentally uploaded a bad version, a rollback to a previous version only took a few administrative clicks.
A good part of my job was to make sure that the companies domain structure and network settings were sensible.
No disagreement about how the web is still easier/cheaper to administer from a centralized point.
Well, that, and all those wonderful apps were inherently client-server architectures, with the business logic on the client. Nobody ever built a properly factored, with stateless layering, and high-end scalability on such an architecture. Just trying to keep 1000 clients in sync, so your business logic remained consistent could drive you to distraction; in a truly distributed product with tens or hundreds of thousands of clients, it was impossible.
Nothing about two-tier architecture prevents you from keeping clients in sync, scaling up or implementing business logic.
Consider that scaling your database has to be done anyway. Your web app will bottleneck on the DB too. The only difference is number of connections assuming you keep them open (but there are multiplexers for that, and many business apps don't need them anyway, RAM is cheap enough).
With stored procedures you can implement whatever logic is needed for maintaining your data.
Of course, if you want to twist VB, or Delphi, or any of the client-server construction sets into pretzels, you could build a well-factored system. And yes, your data has to scale to your system size, regardless of the architecture. But if you use any of those tools (the article was about VB, after all) as designed, you cannot escape the problems I outlined. Your business logic will be either entirely on-client, or split between the client and the database, and it won't be stateless. You will have database connections and transactions spanning thousands of client processes directly to the database, with all the scaling and contention problems that introduces. And you will have an update problem, because updating business logic requires you to push changes to thousands of client machines, which may or may not be available and updatable when you go to deploy your new version.
Can you still build a system, and operate it? Sure. A lot of us did. For small to medium scale systems, it was manageable. But there is a reason we abandond 2-tier client server 20 years ago. While it made building CRUDy business applications vastly easier for the developer, it was a systems nightmare.
(It also led to crappy user experience for any application that wasn't itself inherently a CRUD record keeping job, because it inhibited application designers from thinking of the application as anything other than CRUD. But that's a different argument for a different day).
If you have an ability to force web-style updates on the client apps (which a tool like Conveyor supports, see my other posts or profile), then all you need is a database that supports many connections. You can then atomically upgrade all the clients by e.g. writing a version number to a db table that's checked as part of each transaction, if the version doesn't match the app proceeds to upgrade itself before continuing (unless it's marked as a soft update, i.e. not worth interrupting the user for). The versioning issues aren't much different to the ones you face once you decide to have multiple web servers and rolling upgrades.
I'm happy for you if that's working out in your enterprise. It was not our experience in the time frame we're talking about (VB was sunset over 20 years ago), and frankly it was not our experience 5 years ago - when we were running skads of applications on Citrix servers so we could have absolute control over the "client" runtime environment, and have the actual on-the-glass experience be thin client.
IIRC back in the day, Windows could not replace a file if the file was open by any process. So an application could not update itself, without doing something like launching a separate "updater" and then exiting.
Another thing people tried was putting the VB app on a network share so it wasn't installed on each machine, but I think all the ODBC and other config still had to be local on each client.
And it was so easy for ODBC and other configs to get trampled on by users and installers running amok over existing settings.
Everyone was root on their PC in those days. The opportunity for users to screw things up accidentally was everywhere.