Personally I would be against this. Take GL transactions as an example. I have worked in and managed many accounts departments over more than 35 years, and it is very common to have entering of Payments and Receipts done by different members of staff, likewise with journals and statement matching. One token for all these options would mean all those users had access to all the transactions.
Collections of tokens should represent a job role within the company. We have created some common roles, and allocated tokens to these roles to match an "average company", though I am not sure such a thing exists. Where we have come unstuck, is as you point out, that a number of scripts have the wrong token attached to it. But if that were corrected I would still believe we were on the right lines.
As I said before whenever I am doing a new implementation for somebody I sit down and create a custom ACL for that company. No two of these are the same, though I often use an existing one as a starting point. This isn't a trivial exercise for a company with more than a handful of employees, but as I tell my customers, that is why they need to pay an expert to help them
This does mean that I tend to ignore any oddities in the default, when perhaps I should be fixing it.
Tim
