I would be very interested in that book. My university did not provide explicit book sources, so I can't tell you what that is based on, but here are the relevant slides (from page 9). Server-side hashing is so ubiquitous as the standard that e.g. OWASP cheat sheet doesn't even explicitly say it, but their recommendations hint at it.

A quick google search on the topic revealed others with the same opinion: stackoverflow stackoverflow. The second link (accepted answer in the same thread) argues that with a protocol around it, it can make sense, but never in the situation described here. There needs to be a meaningful computation on the server's side, otherwise the described scenario can happen.

It's a bit difficult to find papers on that because server-side hashing is standard, but here, for example, is a paper that explores client-side hashing (see the introduction with a reference to server-side hashing and section 2): Client Password Hashing paper. Very interesting is also section 3.4. Similar paper: Client-side hashing for efficient typo-tolerant password checkers. Essentially, both suggest that to avoid the described attack, both server-side and client-side hashing is necessary (but the server-side hash can be weaker), see "Authentication attacks after leaks". Neither paper describes how the client-side hashing is done on the Chinese websites they mention.

You'll also find that many frameworks (e.g. ASP.NET, Laravel) implement server-side hashing.

My conclusion from the little research I did after your prompt is that client-side hashing can work, but it's dangerous if done incorrectly (e.g. when done as suggested above), due to the scenario I described.