This is indeed by design. No events are sent to elements that aren't part of a panel, because events are tied to panels (for example there are some differences between how editor panels and runtime panels process their events).

Also, MouseLeaveEvent isn't sent immediately when an element isn't found under the mouse. Instead, it's sent as part of a process of updating the element under the mouse, which happens through an event queue, and the DetachFromPanelEvent is processed earlier, with a higher priority.

We don't want to change the order in which events are processed unless this becomes a real generalized problem that requires a larger redesign. What we recommend is to always consider using RegisterCallback<DetachFromPanelEvent> as an additional entry point for code that react to their elements losing their hover state, or focus state, or pointer capture state, or any other on/off state that usually comes with events for both sides of the change.

It's not impossible that this could change in the future, like MonoBehaviours receiving OnDisable before they have OnDestroy called. Simplifying edge cases in the event system is a goal for the future, but it shouldn't hurt any forward-compatibility to keep a local bool to track the status and react to DetachFromPanelEvent as an additional precaution, and it will work now as well as in the future in any case.