They're stored in a password manager, but they're typeable if needed. My "security question" answers (mother's maiden name, etc) are generated the same way, unique per use, and also stored in my password manager.
Most sites don't need 128 bits of entropy. But things like banking or subscriptions should have at least 112 bits of entropy. And it's easy to just set the generator to 10 words by default.
It's a lot nicer being able to check if I typed in my Peacock login at my parents home at a glance versus a string of random characters.
In most cases I just comply with their dumb policy and put a snarky comment for my future self in the Notes field of my password manager and it makes me feel better.
Is correct-horse-battery-staple guaranteed secure to the heat death of the universe? No, but good enough that it'll take a targeted attack several months to guess.
On the other hand, "rundown skyline pluck shawl pastrami radar refueling poach prankster durable" is far easier to type and is about the same entropy
https://github.com/redacted/XKCD-password-generator
Not sure how many bits a "good" password should be nowadays.
But the point is that you don't control the website's hashing algorithm, or whether they hash at all, or whether they store their hashes in a public s3 bucket. They may tell you what they do, they may not. But you have to trust them either way.
A long random password using a variety of characters is the only control I have when setting my password. If they have a good hashing system and protect their hashes, my long random password will not hurt anything. If they truncate my password before hashing, it will still be the best password I can make for that app.
If I use 5 5 letter words as my password and they truncate after the first 10, how would I know? My password might be "horseapple" instead of "horseapplehappygreennymph".
If I give them 10 alphanumerics and they leak their md5 hashes, I'm pwned in a few days, assuming they even salt it.
If I give them 20 random alphanumeric+symbol then I can't imagine what exotic thing they could do wrong to make it less safe than any other password I choose.
I might make an exception for some streaming service that I have to enter by hand on a tv remote control, but otherwise i am going to generate it with max entropy because I am never going to look at it anyway.
There are many scenarios where an attacker might be able to grab the hashes, but still need to crack them in order to get access to other data from your account. If there is a sql injection vulnerability in the authentication service, for example, it does not mean they can necessarily overwrite the hash or access data in other parts of the application.
I once found a bug in a payment processor that let me download the user record including password hash for all users in that payment processor. But I couldn't use that to get their stored credit card numbers directly. However, if I had brute forced those hashes, I would have been able to log in as them and access their other account data and make transfers, etc. I am sure a large majority of those password would have been very easy to crack. If I was an attacker, those would have been my first targets.
I very rarely have to manually type in a password.
(This isn't to excuse silent truncation.)