Sorry for the trouble and the lost time!
It's in line with the effect an authorizer has when it denies an action: https://www.llblgen.com/Documentation/5.4/LLBLGen%20Pro%20RTF/Concepts/concepts_actioncombinations.htm#effect-of-an-action-executed-on-an-entity-which-doesnt-have-the-required-action
Why the entity had different allowed actions is indeed a little odd, did someone map it to a view and then back to a table perhaps? Was it changed for other entities as well? COuld you verify with source control when this change happened and perhaps track down if it's user error or if we have to look into whether it was a bug in our code?
About the proposal of an exception: I understand the need and agree with it, the problem is that in your situation it wouldn't have helped you: the exception would always be an opt-in setting (as it would be a big breaking change to enable it by default which we don't want to do) and as you weren't aware you needed this, it would likely not occurred to you to enable that setting if was present.
This is also the reason why it's not implemented: it's a good idea but in practice the people who would benefit from it wouldn't know about it at first unless they had read the particular documentation about it.