It's important to distinguish JSON and other data interchange formats from Swift, which is a programming language.
JSON encodes data. Ignoring any implementation differences among JSON parsers, the data you encode is the data you decode every time. It's static, structured data at rest.
You can encode information in Swift code, but decoding that information requires a Swift compiler. Nearly all systems can decode JSON in-process, but fork–exec-ing swiftc is a nontrivial runtime dependency for production systems.
But even setting that aside, there's a fundamental problem of not being able to guarantee constant evaluating of a Swift file. For example, consider this hypothetical Package.swift file proposed by @cukr in the registry proposal thread:
By the same token, you could imagine a malicious package adding long sleep() statements or performing file system operations.
@daveverwer could decide to use Swift as a sort of intermediate representation for JSON-LD, but he'd have to weigh the potential benefit of editor support and semantic type-safety with these operational and security considerations.