Reams and reams of absolutely useless tests that may not have
checked anything that mattered, but that did bump the coverage
metric up.
I would go farther than that, and call those tests worse than useless. Tests that are written to appease some kind of automated coverage metric god tend to be tests that test internal implementations rather than API contracts. So you end up with a codebase where a single line change to production code requires something like 150 lines of test code changes, all because the internal representation of some data was changed in some kind of trivial way.
It's possible to avoid this failure mode, but the teams that are smart enough to avoid this failure mode are also generally smart enough to avoid having unreasonable coverage goals.
