Yes - Aim at Zero Technical Debt

Yes, this may sound too strict, but a breakdown of the kinds of Technical Debt may make it easier to agree with me.

It is zero of specific, very unhealthy types.

I recently stumbled upon a great post by Steve McConnell, which formulates very nicely the concept of technical debt.
(Some other great posts on this topic include developer-debt and knowing-costs-of-development-choices.)

To summarize it,
the taxonomy of technical debt is:
Non Debt

   Feature backlog, deferred features, cut features, etc. Not all incomplete work is debt. These aren't debt, because they don't require interest payments.

Debt

   I. Debt incurred unintentionally due to low quality work

   II. Debt incurred intentionally

      II.A. Short-term debt, usually incurred reactively, for tactical reasons

         II.A.1. Individually identifiable shortcuts (like a car loan) - Healthy

         II.A.2. Numerous tiny shortcuts (like credit card debt)

      II.B. Long-term debt, usually incurred proactively, for strategic reasons - Healthy

I couldn't agree more about the only healthy kinds being being the marked ones.

This leaves us with two unhealthy types.

As for the first, "Debt incurred unintentionally due to low quality work" - Hopefully you have some mechanisms in place to eliminate most of this - enough good developers in each area, mandatory code reviews etc. If not, then a whole other set of posts would be relevant.
Plus, if you’re reading this then you are probably already aware of the technical debt you are incurring :)

"Numerous tiny shortcuts"

This is the kind I want to talk about, and I realize now that my previous post on Demo Leakage may have been a sub type of.

This is the kind of debt that is accumulated  by "taking hundreds or thousands of small shortcuts--

generic variable names, sparse comments, creating one class in a case where you should create two, not following coding conventions, and so on". 
It may also include some crazy nested ifs, comparison to hard-coded inline strings, etc.

The way to present it to the business staff/upper management is depicted in a way that sounds very easy to grasp:
"..like credit card debt. It's easy to incur unintentionally, it adds up faster than you think, and it's harder to track and manage after it has been incurred"

Why is the kind bothering me?

Because the above cute description of technical debt doesn't seem to hit home with managers.

Because it is this type that makes us software craftsmen  cringe, it is this stuff that inspires posts such as this.

It is this type that we recognize us the ugly, and we know WE are going to pay off the debt, not the management that decided this debt was ok.

We know what the REAL interest rate is, even if we cannot quantify it exactly for the non technical staff.

So, why Zero Technical debt? It's Zero of this type. The other types we can handle.
The other ones will not necessarily be needed to be fixed in this version, and when they do it will probably be easily recognized and understood that it will take a significant effort.

I argue that we, developers and team leaders, should strive to be as close to zero as possible, by not introducing any of these shortcuts to begin with.I think that code containing these shortcuts is simply not ready for check-in.

Why is it not worth discussing and trying to decide if any such shortcut is worth it?

• Because management will tend, more often than not, to think that the debt you're proposing is reasonable, because every time it's just +1$ on the credit card.
  They do not have the mental picture we do of the other $$ already there, and they definitely do not smell the code smells we sometimes do in order to realize that this one extra $ may topple everything over.
• It's almost never worth the time estimating the "interest rate" - almost every such small hack could simply be solved during the time it would take to discuss it.
• I think that the effort that goes into explaining this kind is not worth it. It usually involves intricate details of some implementation, and it's hard even for us to quantify the real damage.
• And most importantly - you will almost never get the approval to pay off the debt. Until, that is, you "have to" add another feature.
  Then you're stuck in maintenance hell as well as under time pressure, with management that doesn't understand why this tiny addition requires 3 days of work.
  In my experience, you will never get a product manager's approval for a task called "refactoring X".
  We should not present it as something that can be weighed against other features. It is simply part of the work that needs to be done in order to call something "Done Done".

Concern for "over-engineering"

Would be the first response I would get to this from my manager  - but I think that's more of a danger in other types of debt.
Yes - there is the chance of some over-engineering, but you should have developers/team leaders in place who you trust to know and exercise the right balance.

As for the few cases that will escape this process and will get a bit over engineered -
Well, I would choose "wasting" an extra hour of design and a  solution that is " a little too generic" any day over wasting twice the time a week later on maintaining a hack.
And over time, 1 out of 10 times of a bit of over engineering balances out with the other 9.

And an anecdote for the end - one of the comments from the following post :

"...Likewise, if you ask any professional to do something they know is wrong or will lead to disaster, they will tell you "NO!"
-- Ask an Architect to place the walls such that they don't load the weight properly, or an electrician to wire the outlets in one big circuit, etc.

… Git R Done is good, but not if the 'Done' involves endangering the customer's software's long-term stability.

… And the only ones to blame for that is Us, the software developers, for not standing up and saying "NO!"
when the customer asks for a gun to shoot themselves in the foot."