No. Estimates have a very real purpose, even beyond communicating to managers and customers (whom you should be honest with anyway). Our estimates are used as a team to figure out how much work we can commit to in a sprint. They are also used to determine if you are getting better at things. When we start a project, we don't really have a code base, and many tasks are "new". I expect my estimates to be really wrong at first, and then when I'm implementing things that are very similar to what I've done before, I expect those estimates to get better. I can't really measure that if I'm producing bullshit CYA estimates.
My interpretation of the advice was not that it's intended to mislead, but that it's expected to be more accurate than your initial guess.
my rule of thumb was if it takes 4 hours to develop, I'll always said 3 days, as then You account for some unknown, testing, building / deploying, maybe some refactor after review, etc esoecially as it was for a product that will run for 10-20 years, with changes allowed like once per year. In 60-70% I'd finish in 1-2 days, but in those 30% it's always good to have extra day available for additional development or debugging or anything else or You can always tell You're finished ahead of scedule and feel really good about Yourself! :D