If I understand this correctly, this exploit only works with macros that evaluate at least one of their arguments, otherwise no code is actually run. These kind of macros are not that common. I guess one possible fix would be to mark these kind of macros as potentially dangerous and do not expand them automatically for things like code completion and such.

The qualifying term is 'trusted'. If you are running an application like emacs you damn sure better trust it. It's like running Windows and saying you don't trust it.

AS for macros in lisp, they are not as ubiquitous as it might seem to an outsider. I write lisp professionally. I write one macro a month, if that, and often I rewrite it as a function afterwards. Saying that macros are ubiquitous in lisp is a meme. To most lispers macros are last resort

Microsoft office macros are not Lisp macros.

When you load a Lisp source code file, each of the forms and that file is read and executed.

You know like pretty much any scripting language.

You don't need a macro to perpetrate damage.

Bash doesn't have macros. yet it's a very bad idea to do this:

  wget https://url | bash

Lisp macros execute even when a file is not being executed but only compiled. What that means is that you have to trust a file in order to compile it because by doing so you're running it.

Besides compiling any other tooling which expands macros is vulnerable to execution. As we can see in this article, there our situations when if you're working with list code inside Emacs, it will expand the macros.

If you were going to blindly run the code anyway, that makes no difference. But developers often look at untrusted source code with no intention to run it and not expecting to do anything harmful just by sitting in their editor.

In principle Lisp macros could be sandboxed. The vast majority of macros do not need to do any system access. They just look at their argument code pieces and calculate a new piece of code, without any side effects or accessing anything in the system.