This is usually about a mix of scalability, responsiveness, and partition resilience; with the level of importance of those being dependent on the application.
* Scale: if the client makes fewer request of the server(s) then you have reduced server and network requirements. As server resources get cheaper (and the cheap options more reliable) that side of things is becoming less important, but the network requirements extend far beyond you and almost all the way to the user (see the following two points) who might have a very slow connection at times.
* Responsiveness: the more that you can do client side the quicker your application will feel to the user, even if there is a delay in updates actually hitting the global view you can make it look/feel instantaneous (though you do start to have more problems wrt conflict management when people are collaborating). Have a look at the different methods online games (where real responsiveness and the appearance of instant iteration are vital) manage this.
* Partition resilience: if the client can keep working for a while without needing to talk to other hosts, perhaps queuing updates for reply when communication is restored, your application can keep functioning if there is an issue at your end (glitch at your server provider perhaps) or the user's (on mobile and temporarily in a radio blackspot?) or in between (i.e. a routing issue between ISPs). Even partial resilience is better than none: even if I can't see other people's updates until I'm back in a good signal area, if the app calmly tells me so but allows me to continue to add my work and review already locally cached information I can continue to work (or play!) in a way that wouldn't be possible if more of the logic were server-side.
I have never seen anyone make those arguments. I've seen people vaguely reference them in a hand wavey "I don't understand this but google facebook I am right" way. But that's as close as it gets. It is usually about following trends.
But this particular trend started from an effort to push things client-side for good reasons that are vital, or at least useful, to many projects. It being trendy doesn't necessarily mean it is wrong! Don't be so fast to dismiss something because to don't immediately see/understand the benefit.
There is often some confusion between "mobile first" and "offline first" - the two overlap considerably but being a good mobile app doesn't absolutely necessitate being able to operate offline and offline capability does not require or imply an app will be usable on mobile (it may be to large and/or fiddly in terms of UI on a small screen, not practical to use in a touch manner, or too demanding of CPU and memory resources). Some of the hand-wavey-ness is people who know they are driving for "mobile first" and think that means they have to drive for "offline first" without really understanding the benefits & implications of that.
Before, web development was more like, "fill in this form and when you're ready hit submit and we'll check it." Now people are implementing word processors and music libraries.
However it seems like this has been taken way too far -- I run into a fair share of developers out there who look at basically any proposed web app and say, "Oh yeah, this needs to be a SPA built with React." Why? "Because it's better" and then a rattling off of generic reasons that SPA and doing everything client-side are superior. This is basically the modern version of the Lisp fanboy, they find a good hammer they want to work with more and now everything they see is a nail.
These are often the younger guys who have not yet seen this pattern carry itself out over a generation or two of developers -- if there's any reason why tech ageism is amazingly dumb it's this one imo (have the guy on your team who's graduated past the fanboy stage make your tool, platform and framework choices, you will save far more than the premium that you have to pay him).
Moreover, we've already had applications written in client-database architecture, and it was nowhere near pretty. Fortunately they died long ago, but unfortunately they're resurrected now again.
If the 1995-2005 trends had continued, by now internet services would be served by 15 GHz servers and low-latency 1-10 gigabit networks.