The receiving type should control the lifetime of any callbacks to itself that it gives away. The destructor is the best place to ensure this gets properly cleaned up.

Like anything, custom callbacks can be used well or misused. Design is a matter of expertise and taste bordering on an art form. Connecting framework implementation and business logic can be done cleanly or clumsily. I am skeptical of an argument that callbacks have a code smell prima facie.

This has not been my experience. But I haven't needed to deal with RTTI disabled.

By RAII, I mean using destructors to unregister a callback. This covers 99.9% of use cases. Generally callback registration is not where you really want type erasure anyways.

Regarding your fourth point, sometimes an architecture can be vastly simplified if the source of information can abstracted away. For example, invoking a callback from a TCP client, batch replay service, unit test, etc. Sometimes object oriented design gets in the way.

To your first point, I think RAII and architecture primarily address this. I'm not sure that I see callback implementation driving this. Although I have seen cancellable callbacks, allowing the receiver to safely cancel a callback when it goes away.