I keep my feet squarely planted in two worlds when it comes to development. One of those is all things front-end, and the other is Ruby (and Rails).
With Ruby/Rails, they’re frequently maligned as a not-serious programming language/framework pair because they focus on developer happiness more than pure performance. They follow a philosophy that the productivity gains from a happy developer far outweigh any performance losses from being less performant. That’s not to say that they outright ignore performance, but it isn’t the only or even primary goal. Nor should it be.
Increased bandwidth costs may be somewhat of a concern to the developer, but with the exception of the savviest organizations, I’m not aware of front-end developers giving significant consideration to bandwidth bills. Bandwidth costs might receive lip service, but given that the average page weight has gone from about 500Kb in 2010 to almost 2,000Kb in 2020, the evidence shows it’s not a significant consideration.
The unfortunate reality with pushing the performance burden to the front-end is the lack of reliable connections, and those aren’t just about being hard-wired to fiber or on mobile. Everyone at some point has a less-than-stellar connection even if only from concrete or metal walls and roofs, and it becomes crystal clear when a site works well on a thin connection. Disasters are a great example of this. Connectivity can be incredibly limited when disasters affect infrastructure.
The performance tradeoff isn’t about where the bottleneck is. It’s about who has to carry the burden. It’s one thing for a developer to push the burden onto a server they control. It’s another thing entirely to expect visitors to carry that load when connectivity and device performance isn’t a constant.