Only if you understand the impact of the decision you are making. Most people that use this mantra don't!
Its one thing when its "Tony is out of town, I will borrow his lawn mower and ask for permission later." Its completely different when you don't understand the implications of the thing you are doing.
I have been the "permission granter" thousands of times where permission couldn't be granted due to everything from in feasibility of the request [There are not that many widgets to give], prioritization [its not worth taking from the main product to feet your pet project], compliance [doing what you want will get us fined], to flat out legality.
Developers with this attitude RARELY understand the implications, even in a company of 20 people. They assume that they are getting things done but really they are just moving the problem to a team further down the stack.
Within a company, going around a permission giver is almost always a good way to be labeled a "dick" by the people cleaning up after you.
A person who always follows the "ask permission" strategy ends up with an ingrained unconscious belief that most things they could do are ultimately bad ideas. They end up limiting themselves and only taking actions that are safe, uncontroversial, and unlikely to result in a "no".
A person who always follows the "ask forgiveness" strategy will end up getting slapped down a few times and occasionally get a reputation as a dick and have to find new people to work with. But over time, he'll learn a good intuitive sense of both what the limits are (because he's broken them so many times) and why the limits are there (because he's seen the consequences of breaking them).
All this means that eventually, the person who asked forgiveness a whole lot eventually ends up being the "permission granter". Eventually he ends up taking an opportunity that the "ask permission" folks deemed was too risky and it works out, and people remember the one huge success more than the dozens of minor messes.
So while you may be justified in labeling the "ask forgiveness" guy a dick, that won't stop him from replacing you. Life is sometimes unfair, and assholes sometimes win.
I see the other pattern - the forgiveness guy grows a rep as the guy who broke stuff, while the "ask permission" guy often finds out people say "yes". The end result is people are happier working with the ask permission guy.
Asking forgiveness entails taking a personal risk. If it works out, you're wonderful. If it doesn't work out, you have to answer for your bad judgment.
Asking permission is a way of hedging against your own judgment. In other words, it's a great thing to do when you're genuinely not sure. But if you are right, you don't get results as efficiently, since you have to let everyone bikeshed first. Maybe you don't even get results at all.
I find another pattern works well. You ask permission for ridiculous things, in order to focus other people on what you want to do and how they can help.
It's really simple. Don't open with what you want to do, open with what you'd like to get, and make sure that you're mentioning 2 or 3 things you're willing to give up. Don't say "I want to write a complex mobile app for the delivery department", say "I need a $200k to hire 2 programmers, buy 30 different phones, and 6 months of nothing on my plate, you got 15 minutes ?".
Obviously, you do this once every 6 months or so at most, preferably less, and follow through.
It's amazing, especially in America, how mentioning dollar amounts focuses people on solving problems and looking at opportunities instead of looking for excuses. Finding excuses is universal in organizations, especially big ones, and the higher ups have as much trouble with it at the cleaning lady. Plus, the fact that you even know how much to ask and have a plan for the negotiation means you have built a business case (don't go in without one).
Obviously if you're doing something with compliance/legality/security implications it's worth asking permission. And obviously, you should build processes around those areas in your company. But healthy companies also heavily encourage individual initiative to achieve results rather than relying on top-down command-and-control. If you're a startup, it's doubly important because you just don't have enough people to set up a bureaucracy of permission-givers.
If your employees don't have the judgment to know when to ask for forgiveness rather than permission, fire them and hire people who do have good judgment. Don't use process to protect yourself from hiring bozos. Just don't hire bozos.
Much of the time you should ask forgiveness rather than permission, you're not really required to ask permission in the first place and you just end up creating useless bikeshedding discussions. If there's a process that requires you to ask permission, and the process is genuinely important, it's a different matter.
It's worth noting that the first person to say "it's easier to ask forgiveness than to get permission" was Grace Hopper, who not only wrote the first compiler, but served for four decades in the Navy. So you can accomplish a lot of things and still somehow not get fired from even stodgy bureaucratic institutions with this mentality.
I'm sorry you've had to work with a lot of dicks and bozos. I had a coworker like that once too. Had. I've used, and seen used, "forgiveness before permission" many times in my career and aside from that guy it always worked out.
Its one thing when its "Tony is out of town, I will borrow his lawn mower and ask for permission later." Its completely different when you don't understand the implications of the thing you are doing.
I have been the "permission granter" thousands of times where permission couldn't be granted due to everything from in feasibility of the request [There are not that many widgets to give], prioritization [its not worth taking from the main product to feet your pet project], compliance [doing what you want will get us fined], to flat out legality.
Developers with this attitude RARELY understand the implications, even in a company of 20 people. They assume that they are getting things done but really they are just moving the problem to a team further down the stack.
Within a company, going around a permission giver is almost always a good way to be labeled a "dick" by the people cleaning up after you.