If your system started out with tens of requests per second, and it was designed for that and it works fine under that load, having it break if the load increases 10x is not technical debt
Or it might not even have existed (or was unstable) when you started work, but it got better later.
I'd also urge you to use higher-level languages from the get-go. If you can use Rust instead of C, do it. If Haskell is appropriate, use it. These are all choices that are fantastically easier to make early on than later.
Its the same readon why I almost always immediately use vue or react. Because it doesnt cost me much (~0) but if that thing has to scale i’ll be ready
Obviously there's a bit of YAGNI in tension here.
But if you have the experience to write it correctly from the get-go at low additional cost, then it's worth doing that instead of risking a massive rewrite later.
I have never had any problem with putting some code into a library after the software is done. It is almost always a 1-4 hours exercise, and when it's not, it's a 2 days task at most.
Async code is also something that I have never seen it being a huge problem. Mostly because only a small part of your code needs to be async, most of it can stay synchronous, scheduled by the small async part.
Thread safety is a real problem. One can indeed trade some of it for some development speed, and this can become a huge bottleneck later/soon.