I am personally a big fan of Task's discardableResult closure initializer – it declaratively shows that you are creating a new Task. It carries much more cognitive weight than a simple free function, which I personally find awkward to use. Although this may be my functional programming mind speaking, I actually prefer that it's in a closure initializer that side effects are executed, and not in a free function which I usually prefer making pure (just like min, max, cos, etc.).
Although this is unfortunately undermined by other free functions such as withTaskGroup or withTaskCancellationHandler, there is still another important "declarative" API with side effects: async let.
Task { ... } and async let will undoubtedly be the most widely used structured concurrency APIs, so I actually feel that the declarativeness introduces some consistency to the API.
Furthermore, just because an API design in unprecedented in the Standard Library doesn't make it de facto undesirable / a bad thing. API design evolves with the new features and paradigms Swift gains. Declarative APIs are gaining increasing popularity in Swift thanks to features such as Result Builders and libraries such as SwiftUI, Combine, Argument Parser, etc., and the standard library can (doesn't always mean that it necessarily should) evolve with that.