The BlockReceiveGameEvent was originally introduced as an API event to catch sculk sensors receiving a vibration.
With the release of 1.19 we got two more vibration sensitive constructs in the game, the warden and the allay.

Both of them use the existing vibration listener logic to receive vibrations.
As a byproduct the BlockReceiveGameEvent is called if either of them receive a vibration and contains their current position as a block.

This obviously completely breaks the concept of the event, firing when it isn't supposed to.
Fixing this will be rather ugly, as generally a parent event for any vibration receiving object would be fitting (ObjectRecievesGameEvent, the naming is obviously just an example) that is extended by the BlockReceiveGameEvent and a new EntityReceiveGameEvent.
However the BlockReceiveGameEvent already extends the BlockEvent which makes the usual event hierarchic difficult/impossible to achieve.