Tracking it? Doesn't take too long to set up in some situations.

Increasing it? Depends on if that's trying to get to 100% or just to have a metric to see where tests are needed.

It's usually not productive to enforce it for long ongoing development projects (aside from maybe "stay about 70%" or something). It can be a neat metric, but I don't think it's very productive. Testing comes in the form over very unbalanced importance (see "Pareto distribution"). Start by testing the most important business critical functionality and then move out from there. 20% of your tests will cover 80% of your actual important use cases.

The trade off would be easier to manager if tests didn't require maintenance, but to get the best bang for your buck, focus on the most critical stuff first. Code coverage is by no means a necessity.

The author also points out that these bullet points will not apply to every unique situation.

If your goal is to allow devs to go fast at the cost of more hardened code, then yes, skipping code coverage is a major way to code faster. There are definitely times when it is appropriate to skip writing tests when the primary goal is to go fast.

It's difficult to answer your question without knowing your specific situation though.

I'll take a system with 70% coverage that's focused on the really complex pieces over a system with 99% coverage that's mostly checking that "person.Name" returns the name.

Your engineers should know where be dragons in the code and unit testing appropriately.