There are some things that need to be implemented by both client and relay in order for them to work properly, but there's plenty of things relays can implement on their own without clients needing to do anything at all.
I think one of the most important things relays MUST do for their own continued existence, is mitigate spam as best they can, or else they will quickly fill up their data-stores with garbage that no one wants to see. Each relay must determine for itself what it considers to be spam, and the methods they use to combat spam should require as little cooperation from clients as possible. That said, they should be able to implement things like PoW as a spam mitigation method and expect clients to support it, because that has been a core NIP for quite some time. NIP-13, as a matter of fact. See the details here: https://w3.do/Z86qR9oX
Another thing relays should do, for their own safety, is moderate reports of illegal content being hosted on their relay. Unless relay operators are VERY good at concealing their identity and hosting the relay in a way that cannot be traced back to them, they could face serious legal consequences if they do not remove illegal content, but continue to allow it to be available from their server.
I do want to respond to a few other things you mentioned directly.
"It seems to me that more people will run clients than relays..."
This is ABSOLUTELY true, and clients should give their users a lot of control over what they see, regardless of what content is available on the relays users are connecting to. It's a both/and, rather than an either/or when it comes to whether spam and other unwanted content should be filtered at the relay or client level.
"And you can only connect to relays that implement all of the features that your client expects..."
This is not the case. You can connect to any relay, regardless of whether it has features your client supports. How useful that relay will be to you will depend on what your client supports, though. For instance, you might connect to a PoW relay that allows anyone to read what is stored on it, but requires a certain amount of PoW to write to it, unless you are on a white-list. If your client does not support NIP-13 it will simply be unable to write any of your notes to that relay. It will still be able to connect to it and read from it just fine.
"OTOH, pushing all of the complexity into clients results in fewer clients that are harder to build..."
This may not be the case. Not every client needs to have every feature. I don't need #Amethyst to have a Nostr integrated podcast player built into it. I have fountain_app (npub1v5u…n0v5) for that. I don't need it to have a music player that lets me zap the artists, that's what I have wavlake (npub1yfg…v6vg) for. I don't need it to have a news aggregator built into it, because that's what Layer3.news is for. I don't need it to have a recipe directory built into it, because that is what Zap Cooking⚡️👨🏻🍳 (npub1xxd…kt7a) is for. And I don't need it to have a marketplace built into it, because that's what Shopstr (npub15dc…yv6e) is for.
We can have a bunch of clients that are very good at ONE thing, rather than relying on one client to have ALL the features. There will always be some clients that try to pack as many features in as they can, but at some point they have to pare it down for the sake of not overwhelming their users or making the client super-sluggish, because it is trying to load so much data all the time.
"But what really matters is that it doesn't matter who does what where because it's all an open protocol and gfy we're living in the future! 🤙 🚀"
I WANT TO ZAP YOU FOR THIS! YES! We're all going to do whatever we think is best, and the things that work will live on while the things that don't work will die.