It could, though it's not clear whether it would be an improvement.
Typed Racket uses macro expansion to translate its typed surface language into a typed core language, and then type checks that core language.
This approach works well because the surface and core languages are similar, and thus the type checker need only handle a small number of core forms.
This approach is limited, however, to constructs that are translatable into the core typed language. For example, a few Racket `for/X` comprehension forms are not supported in Typed Racket because they are difficult to translate.
Our approach alternatively uses macro expansion to type check the surface language and translates it into an untyped core language. Thus it's less limited in the typed languages one may implement. The tradeoff is that the programmer must implement type rules for all forms in the surface language, rather than just the core language.
It's a misunderstanding that has unfortunately caught on among many Haskell programmers. People who say "macros are only useful in strict languages" mistakenly think that macros can only be used to delay evaluation. Of course, there are many more uses of macros, as you point out. Macros can define new binding forms, e.g., in Racket, pattern matching is a library, while it in Haskell it must be part of the core language. Macros are also useful for abstracting over non-first-class language forms like top-level definitions, import/export statements, and even type definitions.
FWIW, the phase system that is the main topic of the article was created for Racket [1], though some Scheme macro systems have since adopted this Racket innovation.
