what are the drawbacks of that approach?
For a start, it's an extra step which other methods of authentication have significantly reduced. It's extra effort for your users. Passwords are... easy to forget, and that can become a problem which defeats their very purpose. Most significantly, strong password rules which are out of touch with reality are an insecurity.
You can observe this through the people who try their most common password on some forum, only to find they got it wrong because of some obscure, abnormal rule which they've forgotten about, and so they go on to parrot ever username and password combination they've ever used into the login fields. What's the point of passwords if you're just going to share them with random strangers like that?
Whenever I notice sites that do this, I'm suspicious that they might be subtly trying to phish for passwords for other sites. As far as I'm concerned, unless you're a banking agency nowadays, you should probably avoid storing passwords if you want to be seen as legitimate. There are better methods which are more reliable and safer.
To elaborate: Unless your users have something to protect, let them use whatever the hell they want as a password. That is, if you decide to use a password, even blank passwords should be acceptable.
Is there a good reason all sites don't use that approach?
I run what some commonly consider "sites" which I give others access to at times, and I don't store passwords or enforce password requirements at all; I use certificates for authentication (like any modern-day technology should), and people can (if they choose) protect those certificates with a passphrase at their end.
My sites are servers, and there's a very good reason I don't want to be storing passwords of other people. If one of my users manages to gain administrative access to my servers, they might obtain other password hashes.
Similarly, you can observe this site, which you likely didn't have to enter a password for because you were already logged into the StackExchange network... and the StackExchange network allows you to login using Facebook or Google, so there's that, too.
Certificate authentication is nothing new; it's been used in PAM for years now, doesn't require password authentication and is certainly even stronger for banking institutions to use than just a password.
generate a long (32+ char), random (with good randomness) password
You could do this, but when you forget or misorganise your passwords, you'll end up giving passwords for some services to other services. If you're happy with that, so be it. The world won't stop spinning if your bank account gets cracked open.
Sorry, but you won't find anyone to argue that generating a long, random password is more secure than generating a long, random private certificate that's used to sign some nonce salt and never directly stored on the servers side.
show it to the user once
You shouldn't show the user (unless the password is for something unimportant, like your internet forums), but instead your SSH key generator should ask the user to repeat their passphrase at the time the key is generated. This has the same effect as visual verification (perhaps even stronger), except you're not showing your "password" in plain text for anyone watching over your shoulder to see...
hash it with SHA256
One might even go as far to suggest that a salt be used. The problem is, you're still storing a digest and your users may still parrot passwords for other services at you. The solution to the "forgot your password" problem is not to try every password you've ever used, thus significantly weakening your security, but to eliminate passwords (from your server).
resetting the password generates another long, random password
Even the strongest password-based authentication schemes have long-lasting flaws due to some other technology, such as email or cell-phones; when either of those becomes the weakest link, you'll find the password option collapses entirely.
The way forward regarding both privacy and security is to use cryptographic keys to authenticate, rather than emails, phone numbers, passwords and pin codes.
In fact perhaps the approach could even be enhanced if instead of showing the password to the user, the site simply displayed a form with the password field filled in so the browser and/or passwords managers could memorize it. The user would just submit the form and would never have to see it.
The solution is to store the password somewhere in memory, so that people only have to access that memory location to find it? That hardly seems like a solution to me. Use something physical, such as a passphrase-protected GPG key on a USB pen drive.