It depends on who you are paying for it, but generally a distributed system is harder to reason about, harder to fix, has weirder edge cases, and much more easily get into situations where it requires even MORE expertise to fix than just having a big honking server.

When you start calculating things that are not just the server, the single server looks cheaper and cheaper. How do you get a consistent backup? How do you do DR? How do you tune queries when it could go to this node or that node? Now writes are going to be significantly slower if you need multi-node commit because no matter what you are racing the speed of light on the network.

Another thing worth thinking about when running anything in parallel is the rather massive increase in error rate. When you're essentially rolling 768x the number of dice, failure outcomes will happen a lot more often than if you just roll the one or two.

It's a scale that transforms a 10 year MTBF to a ~5 day MTBF.

A great point, you will also eventually be in a constant state of failure, and have to turn that into something you can manage, automatically.

Only if your engineering resources and free and unbounded.

Even then I would probably use those resources to optimize software instead.

In the physical world of trucks and cranes no company would make that mistake to try to save 30-80k.