I read your article and I loved it, but there is something I dislike about it.
I may have misunderstood something, so l let me explain.

First, I loved how you described these 3 points:

Those ideas are typically:
We can deliver feature 1 faster but that means feature 2 will take longer.
This feature is going to take longer because of how we approached earlier features. You can see that those are conceptually similar other than the timing. The message is that the developer needs more time to work on these features. Calling it technical debt avoids the need to explain the finer details. You might also say:
We’ve incurred technical debt so we need to clean that up before planning the next features.

I agree with that definitions. Even if there is one point missing in that list: what about maintaining software.

For me, the most part of software life cycle, is to maintain a feature over the time.

OK, you bring a nice feature, marketing is happy, sales too. People tap on developer head "good boy", but then start the real life: maintaining what was just released.

The first part is about a few weeks: people cheers up
the second about years: people scratch their head or cry.

I maintain pieces of software for years. I'm not saying to show off my experience, but to explain what I do for living.
Some are more than 10 years old. Some are only a few months old.

For me, every single piece of code is potential technical debt. Even a piece of code you worked on last week.

As a maintainer, my goal is either to kill bugs, to remove feature, to migrate feature to a new stack or to refactor code.

We are all living in a legacy world, created by the people who worked here before, including us.

Yes, it's part of the development life cycle.
Yes, it's all about technical debt.

Technical debt exists, you can pass away when bringing a new feature. It's a choice. The fact it exists is not an excuse to do not deliver features.
Sometimes, we decide to refactor, sometimes we don't.
As you said, it's about planing.

No matter what you do, you are adding a piece of code that people will have to maintain.

My problem with your article is this:

Consider this choice instead:
You have one feature that you will deliver first and one follow-up feature.
Option A: Deliver the first feature faster with non-ideal code or technical choices to make the second feature easier.
Option B: Take longer to deliver the first feature and perform less rework for the second.
With either option, you haven't created a debt. You've simply made decisions about the timeline. This is called planning and all good plans take some finessing.

That's almost a motivator way to see things. "There is no problem, everything is an opportunity". But you only changed the way to say things. And presented the first option as positive, while ignoring your developer feedbacks about the fact the code is either uneasy to maintain or will be even more difficult to maintain.

I agree with this:

When relaying updates to cross-functional teammates, simply explain the problems and give realistic timelines based on what needs to happen. Blaming a delay on technical debt only hinders transparency and keeps your teammates in the dark.
With your development team, technical debt should not be an excuse to hide behind. Decisions are made, mistakes happen, external forces are at work. Discuss what happened and determine your next steps. Your project cannot be bankrupt by technical debt.

But I still don't understand the purpose of your article.

Technical debt is a part of software development, but I'm not sure about your approach to stop calling it "technical debt".

As if calling a dog, a "grown up puppy" would it, make it more acceptable 😀, a puppy is still a dog.