> these events are sent to identified pubkeys?

On the most basic version, yes. Clients can use aliases as well if they want additional privacy. And those aliases can also be independently registered with relays or simply used to write Spam reports or deletion events. 

> What if the recipient's client can't decrypt the event

It doesn't matter if they can or cannot decrypt. If they are listed as a pTag, they are the only interested party in the event. If they are reporting spam, it is spam and can be deleted.  

 But what is the incentive for them to mark it as spam? What is the incentive to not flood the system with events that then clients have to mark as spam, without even knowing where they came from?

I feel like such a scheme would urgently require the sender to pay the relay to store-and-forward and pay the recipient to bother decrypting it. Else, spam will just remain undetectable and a burden for all. 

 If people are sending me DMs I don't like, I am marking as spam. It's as important as it gets. Otherwise that message will be polluting my inbox forever.  

 On primal, if I don't follow them, their DMs are on a separate tab which I would not check all the time. That's also how the big social media platforms do it. I found a guy's bag and tried to contact him on Facebook and Instagram. He hasn't seen my DM for weeks now as these DM's don't get shoved in his face as they shouldn't.

On nostr we could bribe the recipient into reading our messages but otherwise, unsolicited messages - from ephemeral accounts even - should never cause some inbox notification. 

 There is a big difference between new requests and spam. New requests are fine. People are never going to report them. But everytime I see an impersonator DMing me, for instance, I report right away. Because otherwise I might fall for the impersonators trap in the future when I am not paying attention.