I've never understood this perspective.
The patterns that macros express are still there in the codebase, usually via uncompressed repetition.
You would need to learn the pattern regardless if you used a macro or not, and a macro at least formally codifies the repetition.
Indeed, one can make bad abstractions, or messy extensions to the macro, but that's true of functions or classes just as much.
Not supporting macros seems to me as an arbitrary limitation put in place as a stop gap for a symptom with a different root cause. (I.e. removing expressive power to solve poor engineering or immature macro tooling).
It's definitely easier to mess things up with macros, but it's also easier to mess more up the higher up you go in any abstraction ladder.
Now that I'm writing this comment, the very fact that we have to distinguish a macro vs regular code feels like a design smell to me.
Functions should operate on data or code, and controlling when it applies, comp time, run time, or some JIT, should be a separate lifecycle configuration detail, or decoupled in a different manner.