The engineers developing server libraries have been extremely active in Swift evolution, bug reports (for example, @FranzBusch singlehandedly reported a huge number of data race safety holes that were then fixed in Swift 5.10), enhancement requests, and more. I believe that this community is very well represented in the Swift project and their perspectives are taken very seriously in all of the concurrency language work exactly because they've always been at the bleeding edge of concurrency adoption. Keep in mind that the engineers working on the concurrency language feature also develop the standard Concurrency library, which does contain regular concurrent APIs written entirely in Swift (in addition to APIs built using compiler builtins). That library of course has different compatibility constraints than most packages that are built from source, but its swiftinterface is subject to limited backward compatibility with older compilers, which is a very similar problem. But these are also not the problems that OP is facing - there are usability issues surfaced by incremental migration, especially when you have a lot of main-actor-isolated code and you're interoperating with Objective-C libraries that are built on dynamic concurrency properties. I'm in the depths of real, production apps that use concurrency on a daily basis, in addition to constantly reading the feedback surfaced from others. I understand the usability issues.
That said, it is not okay to debate the qualifications of the engineers who are responsible for a feature you are not happy with. The rollout has been difficult because it's an extremely difficult problem. I urge everybody to focus on the technical usability problems with data-race safety, not the people working on it.
Here's an example of some of the specific technical issues that I and others are currently working on (from a different thread):