Whatever it is you're writing doesn't have to work for the next twenty years. If it's sufficiently simpler and cheaper, it's fine if that project only works for the next five years, and you have to start working on a rewrite in four. By then, you'll either have gone broke (in which case the extra scaling would've been useless anyhow), or you'll have four more years of experience to guide you in how to build the next generation.

In your particular case, that MS Access DB was almost certainly the right choice when it was written, and the gotcha in that story is that they didn't start planning the migration away from Access until it was too late — effectively, they didn't pay off the tech debt when they should have, and got foreclosed on.

An example of really bad technical debt we made in one of our projects was: back when Facebook apps were a thing, another social networking site released an app platform that was very similar to Facebook. Some companies had early partnership and launched at release, but we weren't aware of it and were caught flat footed.

Our code wasn't built to be generic enough to be able to work on anything but Facebook. So what we did was simple: copy the whole project, change the stuff that didn't work right.

The next time a social networking site released a platform we refactored our main code and introduced the proper abstractions so we could use it on all 3 sites. That code ended up working for most of the other social networks that launched an app platform.

I'll use your example: I've seen companies start life as Access databases and make plenty of money, and then pay for the proper rewrite out of the revenues generated, instead of doing it the "right way" up front. (when the costs to do it up front may have resulted in a failure to launch)

I don't think it's the type of debt that's the issue, as much as how you manage it.