Server relief is an old idea that hasn't been widely deployed for, I think, good reason. It's something that makes sense to deploy in a new design, where you control the protocol, the client, and the server. It makes less sense as something to retrofit into a web application.
DoS sttacks on slow password hashes are a phenomenon more heard about than ever seen. Concern about them was raised back in the "salted hash" days, when people resisted deploying bcrypt in favor of "secret salts". In the 10 years since, virtually every major site has switched to some kind of stretched password hash. Many of these companies are (or were) clients. The number of in-reality DoS attacks against password hashes I've heard attributed to these companies: 0. My guess at why: it's trivial to DoS a typical SaaS application anyways, applications don't run hashes on nonexistent accounts, and have to lock out repeated login attempts on existing accounts for other reasons anyways.
Which means, unlike every other vector for application-level DoS, to conduct this attack you need a continuous supply of fresh valid accounts on a continuous supply of untainted IP addresses. Why bother? There's almost certainly a preauth endpoint somewhere that accomplishes the same thing anonymously.
You observe that the server doesn't have to see the password in server-relieved schemes. This is true, in the limited sense that there's no point that the server is required to have the plaintext password resident in memory. But there's two caveats to that benefit: first, that's not how passwords are generally taken from compromised applications (what really happens is that the database of password authenticators is stolen, and that remains the case in server relief designs), second, the assurance that passwords will never appear in server memory vanishes when you stipulate that server relief is implemented in content-controlled code, which can simply arrange to have the password sent on the attacker's behalf.
Of course, the content-controlled language we're talking about here (Javascript) is the classic objection to server-relief, and it's worth recalling the reason why: not that browser Javascript is bad for implementing crypto (though: it is), but that it's the slowest of all the computing parties involved in an attack on passwords. By running adaptive hashes clientside, you reduce the security of those hashes to the lowest common denominator of the servers, attackers, and clients --- in most applications, you'll have to reduce it to the strength of outdated smartphone Javascript.
In serious designs, there are already good reasons to isolate authentication into its own service. More large applications should design and implement auth services, and more and more are. Once you've factored auth out of your monolith app server, it's much easier to scale password hash compute, and do it in ways that allow service providers to take advantage of resources that clients don't have.
Again: I think server relief makes sense in new designs, just like I think PAKEs do. But people read comment threads like these and get it into their head that they should get a PAKE set up for their Django application. That's a terrible idea.
I think I'm on pretty good footing, cryptographically speaking, with everything I've written to this point. This last point I'll make, I acknowledge I sound (to everyone) like a crank. But here goes:
This is my problem with the Password Hashing Competition. In reality, bcrypt turned out to be a uniquely strong, well-designed password hash for the purposes it was most typically being applied for (SaaS app login). For every other application --- particularly general-purpose KDFs --- scrypt got you to something like 99.9% of the optimal outcome. But then, for reasons I don't fully comprehend, we had a giant contest to determine "the best password hash" (the one Argon2 won). The world wasn't asking for it, nothing was really threatening the mainstream password hashes we had before... and now we have a "new" king of password hashes that for most purposes is not materially better than scrypt, and a whole lot of new mechanism being proposed to find reasons to deploy it.
Generally the point I would want to make is that on mainstream platforms, like Django and Rails, the platform defaults are pretty good, and probably all you'll need for the whole lifespan of your application. If you don't know what you're doing, and are mostly going off comments on Reddit and HN, it is possible to do more harm than good by departing from those defaults.