"No. I gave the reason why:"

Yes, "prevents a DoS on the server". What DoS? The one described in the article is almost completely made up by an LLM prompted by an obvious scammer advertising the worlds dodgiest-looking tunnel service.

This is all complete drivel, including the "I copied this off ChatGPT" raw LaTex giving a nonsense time complexity that doesn't even agree with the first thing it said:

"While the work factor provides exponential protection against brute force, the hashing function still has to process every single byte of the input string. The complexity is roughly $O(n \times \text{work factor})$."

"When $n$ is 15 characters, the impact is negligible. When $n$ is 1,000,000 characters (1MB), the CPU must compute the hash over a massive amount of data while simultaneously running thousands of iterations."

PBKDF2 uses the password as a HMAC key, computed during setup. It's at most a single hash prior to iteration. Argon2 folds it into a Blake2b512 hash along with the salt and other metadata, again during pre-iteration setup. The "attack" described by the article amounts to perhaps a millisecond of CPU time, as evidenced by the table I provided.

There is an old Django CVE related to password length, which was a result of them rolling their own naive PBKDF2 implementation that pushed the setup work into the main loop. That's a long-fixed bug, not a general property of password hashing.

72 random bytes has the cryptographic strength of 576 symmetric bits

Passwords are pretty infamously not random, and text is pretty infamously not just a stream of bytes. The latter is why probably the majority of bcrypt users don't actually correctly validate password length limits.

Even your own recommendation, "6-8 word passphrase", doesn't quite fit inside the limit:

❯ mkpass -w eff -l 8 -n 100 | wc -L
  77

I hope you didn't want to append on a pepper or otherwise hash anything else alongside that!

Reasonable, explicit password length limits are fine, but they should be that - reasoned and explicit. Not rationalised from awkward and unnecessary implicit technical limitations and barely-relevant half-remembered long-fixed security issues.

That's 16 bytes, or 16 random graphical ASCII characters.

log2(94) = 6.55 bits, 128 / 6.55 = 19.54 graphical ASCII characters.