I agree with you, except for:
If you want a really "hot" take though, to the extent that all this boiler plate discourages interoperating with C code, that might actually be a good thing. It's extremely important that Swift can call C code, but C code should general be hidden inside an API with clear high level guarantees, since it is often trivial to invoke undefined behavior by calling C APIs directly.
Using C from Swift is not an uncommon thing, even on the Apple platforms. If you control the C API you can take advantage of wide variety of macros and attributes that allow you to create a fluent Swift API for your C code. (Example)
If you "control" the compiler itself, you can take the whole thing into another level with bridging.
A lot of popular Swift Packages use C targets or dependencies. I think that making the C interop more fluent and readable is a good thing.
I am not a fan of making things difficult in order to discourage people from using it. If you (or a developer of a dependency) make the decision to use a C code from Swift, you probably have no other option. You're probably not going to re-implement sqlite3 in Swift. And if your program does not work, purposely complicated syntax won't help you in solving the issue.