Agreed, I think this is more an effort to have a free flow of event and information. It's not that one organization has a monopoly on it, it's that all users suffer small painful taxes at every boundary. Collectively they become rather large and this is a way to address that.
I would say it's more cloud native than cloud restricted. In the past we used to try to bring things from outside of the cloud into to the cloud, now we're starting to bring things born in the cloud out of the cloud.
Let me try my best at this. SNS is a sort of close analogy, except SNS isn't really natively tied directly in the other AWS services. It is from some, but it's more attached, not natively integrated including from RBAC / security and provisioning standpoint. Also, while SNS does have topics, and is a type of pub-sub, it doesn't have filters. So every subscriber gets every message. This is certainly useful, but filtering is also useful.
About the dead letter part. Today Event Grid doesn't give you a place to dead letter, after 24 hours of failure we will drop your messages. We will tell you we have begun dropping and when we have stopped (when you come back online). Also soon we will let you send to queues or Event Hubs if you prefer a pull rather than push model of webhooks.
On the second part, the two other services in Azure you may be thinking of are Azure Event Hubs and Azure Service Bus. Event Hubs is a telemetry streaming platform. It's really quite like Kafka. You get a stream that you can send tons of data to for free, then have a client side cursor to read over it. Service Bus on the other hand is really an enterprise messaging service, with rich features like duplicate detection, scheduled delivery, deadlettering, strict ordering, sessions, all with a service side cursor. Service Bus is much more like IBM MQ or TIBCO.
Event Grid is meant to fill a different role: cross cloud eventing, there events are push and they're usually shoulder taps to the source.
A single application could well use all three, but they would be for different purposes. Service Bus fits well for financial / material changes to things. Event Grid allows all the components to communicate with each other and interested parties (e.g. tell me when inventory is pulled), and Event Hubs would be the telemetry pipe from all of the components and apps.
Good question. Some are interesting, some are just useful. For SQL DW doing something like using Event Hubs Capture feature to trigger ETL into DW is really useful. And generally interesting. For Any datastore (SQL, CosmosDb, others) being notified of create, update, or delete operations is also useful and interesting. I think broadly speaking the three areas where Event Grid will be very interesting are for
Serverless: tie your serverless functions together with Grid.
Operations: make rich provisioning and deployment or scale experiences.
Enterprise integration: use workflow and orchestration services like Logic Apps to perform integration across cloud services, cloud providers, and on-premises.
Finally, the custom topics stuff really makes not just serverless, but any cloud application have some interesting possibilities for event and data distribution and publication.