I ran into this myself as well, and it's not really convenient but I can tell you why this technically is.

The latest error is just a normal transient entity, just like any other entities in the platform it follows the normal rules. As you mentioned in your question the big difference is that you are running with entityAccess applied, that means that platform will validate all access rules specified on the entity. Only if you have access you can see the entity.
On the system module you can read the access rules, as you can see nothing is specified on the latestError entity resulting in the fact that no user will be able to access the entity (if you apply security). Because of this and because you apply entity access you do not have read access on the error entity.

Just as an FYI you can actually look at the access rules on the entities in the system module and look at the security tab, those rules are actually being applied (the exception is user, which is a bit more complicated).

You could try and use the same patern you would apply for normal actions that require elevated privileges, and call a subflow without entityAccess to print/use your latestError entity. It might still be available in the subflow.