This is from the perspective of designing a custom system for doing a particular business function, and its software and hardware are interlinked parts of the whole design (as would be e.g. a cloud platform if that was used for it), and it makes all sense of always considering them together as that enables valuable tradeoffs of one vs another instead of assuming that "this hardware must be powerful&efficient for any system" and "this software should run on any hardware". The software isn't intended to ever run on any other hardware, so in that context questions like "running the software on worse hardware" are meaningless as the software is not an isolated component meant to be deployed somewhere else on unknown hardware, it runs exactly on the hardware you want, and if you can save $5k of software costs by spending $1k of hardware costs then you should do it just as eagerly as if you could save $5k of hardware costs by spending $1k of software work. (Which is quite different from mass market software, where you have to consider small runtime savings multiplied by vary many different consumer devices running the same software)
But for many companies building such systems (custom line-of-business software is probably still the largest part of software development happening in the world) it's highly probable that if you can "bail your poor decisions out" by just buying RAM, that's is far more efficient than rebuilding parts of software - a saved man-month of engineering can buy a LOT of RAM; a terabyte of it is probably in the range where it's not even particularly worth trying to carefully evaluate the options as a well-staffed meeting or two discussing the possibilities can be more expensive than buying a few RAM sticks more.