Let us focus on "Event" and "Message" for now.
Event : Lightweight, used to indicate an "event" only. E.g. an order has been placed. In simplified terms we can say that an event informs about occurrence of something. An event is pretty much discreet. This means that if we have 10 orders placed, we will receive 10 events. You can use your own custom schema to define events or use a standard e.g. CloudEvent. Events can be transmitted over a variety of channels e.g. HTTP, Streaming, Messaging etc. Given that events are lightweight and do not carry verbose information, they are mostly used to "notify" interested systems (pub-sub is one way of doing it, pulling event on a subscription is another way of doing it, etc.).
Message : Verbose, used to provide full detail of what needs to happen. E.g. Order with its line items so that a downstream fulfillment system can use the message to proceed with it. Messages generally follow custom schema as they pretty much "domain" messages and need to fit your own business needs. In specific cases where you need to integrate with a third party system, you might publish your own message schema so that they can understand the message. A good messaging system will also allow you to deduplicate them, group them under a session, perhaps commit a batch of message as part of single transaction, read/write messages in batches. In fact, a conventional message schema allows you to add multiple messages as single message provided it fits the maximum size allowed per message.
Now that you understand the purpose of each, you can pick the associated technologies such that its fits your business needs.
It is not too difficult to mix and match the two and achieve business goals. Feel free to try it.
