Coming from the Amiga, I think command line parsing should be part of the OS, but if the current OSes don't support that, then it needs to go into the language's standard library instead.
When you take into account that many programmers nowadays are "spoiled" by working with Python or Go, they expect such amenities to be part of the standard package, blessed by the language maintainers and agreed upon by the community.
Deferring such amenities to third-party libraries would hurt the pickup of Swift by those who don't have the same strong incentives to do so as iOS/Mac developers do.
Being in the OS is something that sounds cool - it's so convenient! Your dependencies are just there and you don't need to worry about how to package and distribute them...
Once you start getting in to it, though, the pain quickly builds up. Firstly - ok, the library is present, but which version is present? Since the library ships with the OS, the available library version is tied non-predictably to the OS version you happen to be running on, requiring stuff like @available and fallbacks everywhere. And of course, eventually you'll have to define a cut-off point and say that OSes older than version X simply are not supported -- even if you could implement the functionality on them.
Also - since the library is now part of an operating system, that OS vendor presumably isn't going to be happy with an open evolution process. It's important to audit which code becomes part of your OS, since they'll be on the hook for supporting it and it may prohibit changes to the underlying implementation if a certain interface needs to be supported.
We see a lot of these kinds of problems with Foundation, which is why it (IMO) hasn't done a terribly good job for the Swift ecosystem. Really, this kind of thing should go in Foundation.
Command-line parsing doesn't benefit from being part of the operating system. For non-trivial programs, argument parsing will take negligible execution time. On top of that, it would suck if OSes which shipped with a Swift 5.1 standard library (macOS 10.15) couldn't run new scripts because the bundled copy of the stdlib didn't include argument parsing. That code is relatively simple and very portable.
In other words - prefer libraries, prefer higher-level libraries over system libraries, and prefer bringing those libraries with you rather than sharing them. This is similar to (but not the same as) how server apps have embraced encapsulation and containerisation.
I'll answer that: APIs in the standard library might ultimately be deprecated, but they won't silently become ghostware. They won't become incompatible with the nth revision of Swift.
Probably the biggest reason I try to avoid third-party libraries is the risk those two issues create. An API in the standard library, or any other Apple-backed library, is going to remain supported for a reasonable lifetime. Other libraries generally can't make that claim.
I think the standard library should be reserved basic types and standards needed for basic interoperability of different code bases. Although I like the idea of an official Package for argument parsing, I don’t think it belongs in the standard library. The standard library should be as lightweight as practical.