This answer is left open-ended in the hopes that someone with a deep understanding of how animation works can provide further insights and explanations.
An important observation is that the two elements are not nested, despite appearing so in the HTML layout. Your CSS correctly accounts for this by using a + selector instead of >.
When the .hide element is hovered above (in the z-direction) the .hover element, it prevents the .hover element from detecting the hover event.
Initially, when no hovering occurs, .hide is set to display: none and remains invisible without taking up any space.
When .hover is hovered over, .hide changes to display: inline and position: absolute, causing it to overlay .hover due to its position in the DOM hierarchy. This temporary overlay prevents .hover from registering the hover event until .hide reverts back to display: none and removes its absolute positioning.
The lack of flickering, even without unrelated animations, may be attributed to timing and repaint considerations within the system.
If an animation is ongoing, the system triggers a repaint as soon as the position of .hide is altered.
However, if there are no active animations, the system delays the repaint process, allowing the transition of .hide's position to occur within a single frame without causing flickering.
A clearer explanation on how CSS animations handle such scenarios would greatly benefit this discussion.
For reference, the link https://developer.mozilla.org/en-US/docs/Web/Performance/Animation_performance_and_frame_rate delves into animation sequences but overlooks cases involving changes in position and display values.
In agreement with @BrendanMorel, setting pointer-events to none effectively resolves the issue of .hide intercepting the hover events.