This is expected behavior, because of how queue events work.
A standard event player in MPF will post all of its handlers when the triggering event is called, processing each handler according to its priority but also in parallel. Once the handlers have been called the event is done.
A queue event player still processes each handler according to priority, but they are queued up so the first one goes, and the second one waits for the first one to finish before it starts. That wait could be a few lines, a few cycles, or indefinitely (e.g. waiting for a player to push a button). Only after the first handler says "I'm finished" will the second handler be processed. How does a handler say it's finished? By posting the events_when_finished event(s).
If a queue event player has a handler with no finished event, the rest of the queue will never be processed and the game will potentially/eventually hang. If multiple queue event players have the same finished event, it could get real wonky because some handlers might jump the queue and be processed out of order or too early. That's why there's no default value.
It's perhaps an oversight that events_when_finished is not a required property in the config spec. That code is unchanged in almost a decade, from its first release, and very few people use queue events and those that do would always need to include events_when_finished.
So my question is: why is it that you need to use a queue event player instead of a regular event player, if you're not needing the events_when_finished event to know your callback is complete?