I think you failed to understand the second point you quoted.
A 250MB password should be perfectly valid (if a bit foolish on the customer's part). That 250MB password will be run through scrypt by javascript running on the browser. (That may take a while, and a large amount of memory, but this is part of the CUSTOMER'S stack, not the server's.) Some amount, perhaps 512 bits worth, is then passed to the server. (Where it is run through another hash and then stored.)
It's not at all common or best practices to run an expensive key derivation function browser side. Doing so adds little to no additional security -- if you don't trust the TLS channel then you are screwed any way you look at it.
It's not common, but running an expensive KDF client-side still greatly slows down a bruit force attack if the password hashes are stolen, without increasing load on your server. The fast one-way function run server-side then prevents the client from being able to submit a stolen hash, forcing an attacker with a list of stolen hashes to perform the full expensive bruit-force attack.
A 250MB password should be perfectly valid (if a bit foolish on the customer's part). That 250MB password will be run through scrypt by javascript running on the browser. (That may take a while, and a large amount of memory, but this is part of the CUSTOMER'S stack, not the server's.) Some amount, perhaps 512 bits worth, is then passed to the server. (Where it is run through another hash and then stored.)