What makes non-modular solutions make more sense is not the time - there are places where they make sense today and will be places 30 years from now - it is the characteristics of current technology and your problem space.
While it does not make sense today for problems where it did 20 years ago, there are new problems where it arises today, and there will be undreamed of problems where it arises in 20 years.
Also there is a certain relative nature to the issue. There is never an absolute line that this is loosely coupled and that is not. Rather you can say that one design is more loosely coupled than another. For instance suppose that OO Perl runs at half the speed of procedural Perl (there is a lot of overhead in making method calls), then using OO techniques to modularize has a huge overhead. Is it worth that overhead to be able to get the benefits of OO? That entirely depends on what you are doing, and what the capabilities of modern hardware are. And if OO doesn't make sense for you to use today, it might in 5 years.
The result is that software 20 years from now will be able to be shockingly inefficient from the present perspective, just as current software is shockingly inefficient from the perspective of computers 20 years ago. But that inefficiency will buy people something, and one of the things that it will buy them is additional looseness of coupling in layers between the programming abstraction and the actual implementation.