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.
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.
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.
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).
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.
Powerbuilder apps were similar.