Kim makes an excellent point: timing constraints are the biggest reason for an experienced designer to run (or not run) post-route timing simulations. While most clock and IO constraints are pretty straight forward and seldom cause a problem, false-path and multi- cycle constraints are easily specified erroneously, and lacking specialized formal tools to check/generate them, the only way to verify them is with post-route timing simulations.
For that reason, If I don't need a multicycle or false path constraint, I don't use it. I will put in a significant level of extra work in the implementation to avoid them if necessary, and thus avoid the need for post-route simulations.
That said, novice designers should run post-synthesis or post-route simulations just to make sure they're not doing something stupid in their synthesizable code.
By focusing on much faster RTL simulations (especially if you use integers, variables, and only clocked processes wherever possible), more "corner cases" can be covered in less time.
This should be obvious, but Static Timing Analysis is mandatory, regardless of whether you run a full timing simulation.
Also, this holds for FPGA development where the cost of failure is usually rather low, compared to ASICs. That said, there are some rather expensive OTP FPGAs that would fall more under the ASIC verification model, where full timing simulations are justified by the NRE to fix a problem during hardware test/integration.
You have to ask yourself what kind of problems you are trying to detect/prevent: design specification problems, verification problems, tool problems (simulation, synthesis, P&R, STA, etc.), and what are their relative probabilities as well as cost of detection vs cost of repair?
Andy