I consider this wrong on all counts and I don't see where you're coming from to make these claims. You obviously benefit from performance gains on the server and client in standard use-cases.

A Node.js server's main thread is nickel and dimed by a thousand little cuts. A faster hash implementation can reduce loop delay by a nontrivial amount. This isn't heavy processing.

Same with the client. Any sort of game could have a good reason to be doing hashtable lookups in a hot loop on the client. This isn't heavy processing in some exotic use-case, it's rather elementary. And perf trade-offs especially help slow clients. And freeing up the main thread lets you fit in more nonreducible cycles.

Also, moving work to the server because your client implementation is too slow and then generalizing that to "always do work on the server", is tautological. Where you do work is fundamentally a business logic / product design concern that is only a performance concern in the suboptimal case where you can't fit the work on the server or client. So faster implementations move what are performance concerns back into the realm of higher level product design decisions.

These aren't symptoms of "doing it wrong". This is just plain jane software engineering.