To be honest, the boss was the problem. Estimates from developers should be vetted by tech leads and project managers before they are carved in stone and shown to business leaders. Your list of reasons why estimates are incorrect is a good rubric to use when evaluating a developer's estimates. Grade the estimate using the list and the estimates will get better over time.

One other note - as a development manager I had a hard and fast rule - a developer should never, ever give an estimate in a meeting with stakeholders. You get one strike - the second time an exec asks you "How long a piece of string is" (metaphorically) and you don't respond with "[insert name of boss here] and I will review the requirements and get back to you as soon as possible" or just let the boss handle the question - then you get fired. Some might see this type of response as evasive, but you will do the exec and your team a huge disservice by blurting out some optimistic or pessimistic estimate - both extremes reduce your credibility when they are wrong and create the potential for real damage to your company or team.

Your boss is paid more than you for a reason - he's your buffer - use him when confronted with the magic question "How long will it take?"