A bit late to the party, but here's an answer composed from my comments around integration with off-platform systems.
We have historically used callouts to send messages from Salesforce to an external system, and had the external system use the REST or SOAP APIs to provide updates (or call bespoke processing).
On some occasions we have had to do it all from the Salesforce side, using polling to fetch updates from the external system.
It rather depends on the integration patterns that the external system supports.
Keep the integration outside the core package
We have always decoupled this from the core product. IMHO you should always put integrations in a separate "extension package" - now even easier to do given you have the ability to have multiple 2GPs in the same namespace and to have APIs between these that are hidden from package users.
We do this because customers frequently have different use cases for a (possibly common) external system or require integration between our product and different external systems.
Roll your own or use middleware
If you are doing point-to-point integration, rolling your own is OK. However, if you need to integrate with more than one external system it is almost certain you should use middleware to do the coordination, routing, data transformations etc.
See this other Q&A for more on this topic.
Platform Events and why to be cautious
Platform Events have no guarantees for delivery. They can get lost if the infrastructure suffers an issue. For me that means you should not use them to transport valuable data that you cannot reconstruct from the data in the database.
This is covered in the documentation thus:
In rare cases, the event message might not be persisted in the distributed system during the initial or subsequent attempts. This means that the events aren’t delivered to subscribers, and they aren’t recoverable.
Platform Events also have significant limits on CometD (and other) transport. This can prevent you from scaling your integration. Obviously there are also REST/SOAP API limits to worry about, but these are higher.