Hi Goffredo,
A formatter tool that is part of the swift.org projects should be using SwiftSyntax for its functionality. SwiftSyntax is directly integrated with the Swift parser and we are focused to keep improving in terms of performance and convenience for building Swift tools that need to understand the syntactic structure of Swift code. It has performance features like incremental re-parsing so that a live editor will do only the minimum work necessary to get an updated syntax tree after small user edits. Any change in the Swift grammar is going to be reflected in the SwiftSyntax APIs, either from the direct implementation of a SE proposal or at least soon after a proposal is accepted.
To minimize maintenance overhead it is desirable to have a clear separation of concerns for the swift.org projects. That means that the functionality of understanding Swift syntax is going to be provided by SwiftSyntax and other projects like SourceKit-LSP and a formatter tool are going to build their functionality on top of SwiftSyntax, instead of trying to duplicate it.
I'm mentioning this because SwiftFormat has developed its own lexer and parser and it would need work to rewrite significant parts of it.
I'd like to clarify that the NSHipster article compared swift-format using swift-4.2 which only provides the slowest available way to get a SwiftSyntax tree (invoke the swiftc binary and parse a large JSON file) and SwiftSyntax itself did not have good visitation performance. SwiftSyntax in master/swift-5.1 has been re-designed and has orders of magnitude better performance in almost all aspects of using it, like parsing, visitation, incremental re-parsing, etc. Some details on how we improved parsing performance are in this forum post.
Another thing I'd like to clarify about a formatter project that is part of swift.org, is that it will aim to provide the building blocks for doing formatting rule transformations. Regardless of how configurable the resulting binary itself will be, the project will be a SwiftPM project and designed in a way that other projects can depend on its libraries to either use as is or modify its formatting pipeline or even plug in their own transformations. That will allow, for example, SwiftLint (which is doing a lot more than just whitespace transformations), to use the same building blocks and just focus on adding additional rules and functionality on top of the underlying infrastructure. They can be free from worrying about the particulars of handling a Swift grammar construct unless it is relevant for some particular rule.