I'd love these kinds of discussions to bring in the big picture more. In particular the opportunity costs of such a huge endeavour. So without being very technically versed, I want to give my two cents.
Macros by themselves might appeal to some group of users. So would many other potential extensions to Swift. But do they yield the best return on time and attention invested? Are there not features to round out that are more fundamental and add less complexity to the language as a whole? I'm thinking ownership, concurrency and cross-platform portability, just to name a few.
While expert Swift users still have trouble understanding and using a feature as fundamental as Swift's implementation of the actor model, here we're opening this huge can of worms that is a macro system. That feels slightly alienating to me.
Wanting to add a macro system is a sign of a mature and saturated language. A very comfortable but also delicate spot to be in. From there you can make the language more robust, consistent, diagnosable, portable, performant etc. Or you can inflate the language's surface and bloat it with the next best feature we can come up with.
To me personally and deep down, it feels like a design deficiency of language A if it inspires users to want another language B to produce code in A. And I don't think Swift is that deficient. I don't get the idea that this will free the evolution process from having to consider/implement subjective syntax sugar features. To the degree macros are just for subjective syntax sugar, they are by definition non-essential. And to the degree they fill gaps in the language, the language itself should do that.
Also, if Swift adds features, it should continue humbly learning from the languages that are most loved. And that is in particular since years and without close second: Rust.