> However, it has the slight problem of not actually being true.
The slight problem of your explanation showing that you do not actually understand the issue makes this unprovoked snide remark not only unnecessary but also embarrassing.
> First, accessing RAM is (apart from I/O) the most expensive part of your program these days.
That is absolutely true but has nothing to do with my argument, as the cost of access is not dependent (at least not much, and NUMA aside) on how much RAM you're using (once you exceed cache sizes etc.). A thousand cache misses cost the same whether your heap is 100 MB or 1 TB. In fact, using more RAM can make it easier to access RAM less, and so can make your application significantly faster precisely because access is expensive.
For example, suppose a common operation in your program is using the average of a set of numbers (that doesn't change often). Computing that average would require a large number of RAM operations (depending on the size of the set). On the other hand, computing that value once and caching it, would need more RAM but would access it less.
Another example: some modern GCs (like ZGC) have worst-case pauses that are independent of the size of the heap, but the rate of collection increases the less memory you have. Therefore, increasing your heap would only reduce the amount of time spent in GC (because it reduces RAM access by increasing RAM usage).
> Second: yes, there is a relationship between time-saving technologies and RAM use, but it is mostly coincidental, not causal.
It's very hard to learn from old examples because they operated in a very different environment under very different constraints and requirements (also, RAM constraints affected Smalltalk's ability to cache JITted code, and made it less efficient). But in order to make my argument less controversial, let me put it this way: if you can pay for productivity/performance with RAM you're making a good deal.