I can’t speak to swift, but in experience with many other langs and runtimes I will say that single-threaded business logic by default is still the only sane choice even today. There are exceptions both on client and server side, but you get so incredibly far with one thread, while eliminating so many potential bugs, that it’s borderline whether parallelism should even be exposed to application developers at all.

Even in Go which has my favorite parallel concurrency model, there are many footguns and needless walking on eggshells for business logic. You can still offload IO and bespoke compute to other threads when it makes sense. This view isn’t a panacea, but damn close for the 99% of use cases.

Coincidentally I also think the early success of JavaScript an largely be attributed to single-threaded run-loop and callback-oriented concurrency. Even on the server JS is still holding strong with this limitation, and that’s despite all the other limitations and insanity of JS.

Main actor by default is a decent strategy. It's usually pretty obvious when something needs to happen off the main actor.

Apple effectively solves the problem which doesn't exists.

Before Swift 6, I've worked lot of unique projects both macOS and iOS and never spend time on debugging. I don't know what debugging time exactly?

Everything probably already is or should be