Padding: Is this really a "Professional Option" ?

I prefer the phrase 'unquantified contingency.' :-)

The definition given:

"Padding is basically adding extra time or cost to an estimate because the estimator does not have enough information."

...ignores both when and why padding is used, at first glance.

If requirements, design, and WBS are complete, and you are presenting a final project schedule, you'd best not have any padding hiding in it. I wouldn't go so far as to call it a crime (as long as you're not billing for the padding you don't use), but it, at minumum, reflects a potential lack of planning if you are preparing to execute and still have padded estimates. However, if you are in the early stages of a multi-year project, it wouldn't surprise me to find padding in most estimates.

How exact is a 'ballpark' estimate? How quantifiable are the criteria that are used to come up with it? Given enough time, you might be able to come up with a quantifiable rough order of magnitude estimate, but what do you do when you are put on the spot to pull a number out of the air? You can explain risk and contingency, but when you give your best guess without any quantifiable evidence to support it, knowing that you will be held to whatever number you give, knowing that you'll be allowed to revise your estimate to a smaller number, but won't be allowed to take longer than your initial estimate, can you honestly say there is no padding involved?

I think this question has taken a bit of a dark turn. It started with "We all know what padding is, why have you considered using it?" and turned into "It's wrong, you should NEVER do it." Is that padding-shaming :-) I think that 'When' and 'Why' need to be considered in the context of the question. When is padding okay, and when is it not? Why is it used? I also think that the supposition that effective risk management and contingency planning eliminate the need for padding is misleading. When dealing with risks, you're often not just dealing with something that hasn't happened yet, but something with an unclear impact on the project. Any estimates given in response to something that is unknowable might as well be padding. Well thought out padding? Maybe. Delphi method developed padding? Possibly. But padding, nonetheless. Just because you've communicated the knowledge gaps and gained consensus on the estimate, doesn't mean it's stopped being padding.

Look at it from the perspective of software development. If the development and testing effort is four hours, over a three day period, how much time do you estimate for bug fixing? If you have historical data, you can give a rough estimate based on how long something similar has taken in the past. If this is something new, you don't know. You pad your estimate to allow time for bug fixing and retesting, trying to be reasonable. In either case, you could be wrong.

There are circumstances where padding is acceptable. In these circumstances, the padding should be communicated, and there should be a plan to follow up with further refinement as more information becomes available. This plan does not turn padding into something else; it is the refinement into a more accurate estimate that causes the change.

Does this make sense?

I think padding might be intentionally made not because estimators have lack of information but because estimators or team members have less confidence to execute the activities within the frame of the initially calculated time and costs and/ or because estimators or team members used paddings as the ways of escaping from being blamed for in case that the actual works would be carried out behind schedule and over budget.

Lack of detailed information is surely one of key sources of various risks to overall project planning and executing stages but it is hard tot justify paddings. Theoretically, yes, padding should be viewed and treated seriously pursuant to the organization's policies, if any or to PMI's Code of Ethics and Professional Conducts.

I think, including myself, every project manager, team member and estimator might have experiences to be tempted for padding when his or her responsibilities are high to complete the project successfully within approved time and cost.

In my personal opinion, even though padding is considered as a bad conduct or a failure to make reliable plans of the project (poor planning), sometimes, practically, I really doubt if I am able to completely avoid the paddings during estimates of time and cost.

I think you've partially answered your own question - padding or perhaps referred to more professionally as contingency is added to cover unknowns. Over and above that, it might also be included to increase the profit on a project to make it commercially attractive, or to make it so expensive that the customer rejects the bid. Another reason for including it is to protect profit margins if you're expecting the customer to want a lot of technical support beyond what has been budgeted for in the contract.
It might also be added to protect a reputation or to give the PM an easy ride - allows you to under promise and over deliver on a project = still deliver on time and to budget even after delays. The extent you might do that depends somewhat on the culture of the organisation you're working for, or perhaps how aggressive you view your customer.
You might need to do this where you are uncertain of resource availability - in a weak matrix organisation where the PM has little control over resources and the projects he's responsible for are viewed as lower priority in the organisation, it's practically impossible to accurately schedule a project and therefore padding is really only pointing out a realistic situation.
I'm sure other members can add other reasons but I've given a few to get the discussion started.

This is why I like relative estimation (points not effort). There is no need for anyone to "game" relative estimates but it's also valid for the team to build in whatever factors impact their delivery and help them better forecast the backlog. Size, complexity and risk are all valid components of a story point estimate.

Absolute estimates are invariably deceptive (and even self-deceptive) because the people making the estimates know very well that the "ideal day" does not exist. Relative estimaters just don't feel the need to lie about it.