Most of my macros turned into const and static

Same advice holds in Common Lisp, and there the reason is redefinition. A macro that expands into a call to an ordinary function keeps its expansion small, and the function can be redefined and tested without touching any caller. If the logic sits inside the expander instead, every site that used the macro holds whatever the expander produced when that site was compiled. Changing the logic then means finding and recompiling those sites, and a reader of the program has no record of which ones they are.

Half agree. I live in C++, and there the template is both the macro and the generic type, so "keep it small" isn't really on offer. What you can do is move work out of it. Most old metaprogramming is now constexpr functions, which are just functions, loops and ifs included, evaluated at compile time when the context asks. consteval if you want to insist.

Picking an overload by what a type can do got concepts. template <std::integral T> fails at the call site with a note about the unmet constraint instead of three screens of substitution failure from deep inside a library.

A footnote from the CoffeeScript side. CoffeeScript was more or less one big fixed macro over JavaScript, and most of its sugar was later absorbed into the language with ES2015, sometimes with subtly different semantics. Sugar that proves itself tends to get promoted like that, and a small macro is cheap to migrate off when it happens.

Agda is home turf for me, and there's no compile-time sublanguage there to keep small, which sounds great until you pay for it. Type checking normalizes terms, so compile-time evaluation is just evaluation, and anything total can run there. The price is that totality gets checked. The termination checker wants recursion on structurally smaller arguments, and a perfectly reasonable function that recurses on n / 2 is rejected until you rewrite it with well-founded recursion or a fuel argument. Honestly that rewrite can come out longer than the function.

Agda does have macros, through reflection, and I almost never want one.

Worth counting what const table = buildTable() costs. The proc doesn't run once. It runs in the compile-time VM on every build of that module, and the VM is an interpreter, so a loop that finishes in a blink compiled can take a good while there. A table of a few hundred entries, nobody notices. A few million and you hit the VM's loop limit first, the error that tells you to raise --maxLoopIterationsVM. At that size I'd rather generate the table once into a file and pull it in with staticRead, or build it at startup and pay once per process.