Is it a design flaw in SSH that a user is required to check fingerprint manually?
It has pros and cons (surprise!).
Websites use a 'trusted' third party for HTTPS. We all trust the Staat Der Nederlanden, Chunghwa, Atos, and the China Financial Certification Authority to verify your connection between you and your bank, right? Because that's exactly what they're doing, and this has been known to go wrong in the past. But it's the best we got: we can't expect our moms to ring up the bank to ask their fingerprint, so we need to use these semi-trusted certificate authorities.
For SSH, it is mainly used by system administrators or other power users, so it is more reasonable to expect that they check the fingerprint, or at least understand what it is. A security-aware admin can check it, if they wish to do so (for example, I work for an IT security consultancy and we check the fingerprints before connecting). Otherwise, at least it's trust on first use as Sjoerd already mentioned, so it can't just change without you noticing. An attack would have to be present from the start, and has to go on indefinitely, for it to go unnoticed.
It feels like a design flaw: a malicious server can impersonate a user to a legitimate server by doing MiTM and proxying user's responses to the original server.
Same with any other scheme, right? You can always MitM and proxy the traffic. In ssh's case you get a wrong fingerprint the first time or a fat alert upon any subsequent connections, and in https' case you get a certificate warning.
The way to fix that would be to sign not only challenge, but also server's fingerprint. Then the server can detect MiTM server-side.
Think this through:
A: Hello there, SSH server of bob.example.com!
B: Greetings, stranger. Here is my public key: abcdef
M: intercepts the message and changes abcdef to 123456
A: Hi server bob with public key 123456, I'm Alice with password bz8iuqw45.
M: intercepts the message and changes 123456 to abcdef
B: Hi Alice! You logged in successfully!
An attacker will use their own public key, so they can decrypt the traffic. When forwarding the data, they can replace the fingerprint. You would have to do mutual authentication, where the client supplies a public key that is already trusted by the server. Only then does the server know for sure that the client is using the right key and is not being man-in-the-middled. But now you reversed the problem: now the server has to know the right fingerprint (of the user's public key) instead of the user of the server. The issue, key distribution, remains.
Let's assume that the client is unwiling to check the fingerprint because in order to do it it should get the true fingerprint somehow.
Do you mean it's impossible to get the fingerprint, without trusting the fingerprint when connecting? Because you could grab the real fingerprint when installing the server, before connecting via ssh.
I feel like some clients don't check fingerprints at all
That would be a vulnerability in the client. If you want to check fingerprints but your client does not support that, then you can't use those clients. It's a little easy to say "the authors of the ssh protocol did it all wrong, this is causing clients to ignore security", because as I said, there are pros and cons to this default scheme. If you want to change it, SSH supports certificate authorities as paj28 mentioned.