The leaning Millennium Tower in SF cost over >$100m dollars to fix. We call that a mistake or an oversight, not "engineering debt"
In software we'd have called it "technical debt", as if spending $600m to build a system that doesn't work and needs to be fixed at tremendous cost while wiping out all of the profits was somehow part of our business strategy all along.
Software is very different to building the millennium tower - that's designed once, and when built won't be expected to substantially change or grow (at least from a structural perspective, you will change the interior). Building a skyscraper can take 5 years to complete, and when it's built it looks like the design from 5 years ago (with all the same load assumptions). With software the design is expected to change throughout the lifecycle, and should adapt to customer demand and scaling requirements, and you can't wait 5 years for perfect when 'good enough' will do and get you live.
Building complex solutions that you don't really need is also "bad engineering". Part of the complexity comes from the fact that the needs that software projects solve are not fixed, they change during the products life cycle.
Even architects use technical debt, it just comes in different ways. Instead of trying to plan what every room is for, architects leave empty sections, to be determined later. A lot of buildings have little spaces reconverted to closets just because there was leftover space there. That's technical debt, you know the "best approach" (according to waterfall engineering) would be to find out how things will work and then build it, but you'd rather write "IOU" on that section and move on to the important bits. You can then solve the kinks with plasterboard.
The best example of technical debt is code that doesn't scale. You know you should write your code to support 1M users, but you currently have ~100 users. Instead of spending a month serving 990k users you don't have, I would say it's good engineering to solve the problem for say 10k users if that means you'll spend a week, and have the rest of the time to solve other more pressing concerns.
I'm not sure I agree that an engineer experienced in building scalable systems will need 3 extra weeks to pick a schema and data access pattern that's scalable.
You don't have to actually _use_ spanner or cockroach or vitess in your initial prototype if you don't want to, but it seems entirely reasonable to have an _idea_ of what the story would look like to migrate to a horizontally-scalable approach if product gains traction so it doesn't end up being a multi-year project later.
The problem is rather that the technical debt is often not repaid.
That's not a technical choice since the person writing code wasn't aware of the options, so it's a business choice. How good of a business choice is it, though?
We all know at some level that a well-intentioned but inexperienced engineer can make a decision in an afternoon that will take weeks or years to clean up. I often see junior engineers spend several days over-engineering something that a senior engineer would have done simpler and better in a fraction of the time. I don't think it's a given that junior engineers provide better return on investment early on that a senior engineer.
Getting some worthwhile feedback and advice from a seasoned engineer doesn't need to cost a fortune in up-front cash, and personally I think it'll pay for itself. You either compensate them with stock or hire them as a temporary or part time consultant.
For social media kind of traffic it became inadequate at some point and the debt had to be paid (and thanks to success was easy to pay).
To me a smart use of technical debt.
Certain qualities or features like horizontal scalability and security can be relatively inexpensive to design in at the beginning and immensely expensive to try to tack on later once a system is already in wide use.