But yes - for measuring success, it's a terrible metric. One should prefer a project to be delayed, but proper, than delivered on time, but broken.
Features are done when they're done (for a given definition of "done"). Once we're satisfied with what we have, we release it. Otherwise we keep working, or we scope down.
Strict deadlines are seemingly based on financial period expectations, rather than on what actually produces better software, and thus, ironically, more revenue for the same stockholders who were demanding a date. It seems more of a short-term strategy than long-term.
Anyway, that's my pessimistic, armchair interpretation of it.
I know you specifically say "for a competent team", but I just wanted to mention that for a lot of teams, the quote above is absolutely true.
Ok, if you already are measuring impact and has a correct prioritization of it above anything else, adding delivery date and time spent won't hurt. But if you don't prioritize it above anything else, you are simply begging for a huge failure.