The author doesn't even know what macros are: "I understand macros to provide two things (1) forced code in-lining and (2) a kind of non-strict semantics or lazy evaluation of arguments"
As a former professional Common Lisp dev, those two features strike me as the real difference between a macro and function call.
Although, Scala specifically, I ran away from. The language itself isn't terrible, it just forces one to confront the endgame of the bankrupt Java philosophy. The stdlib is basically the cross product of pre-optimized category theory with noun-hell, and idiomatic scala is far too overabstracted through abuse of first-class modules (which, admittedly, was a design goal).
I tried to use the JVM for a long time, I really did. I thought the advantages of multiple implementations, platform flexibility, and a common type system were fantastic. The fundamental problem is that no matter the skin, when you want to peek through the abstraction you're still fundamentally writing Java. I absolutely detest the Java language itself, as it's basically what should come out of a compiler, not be fed into one (I realize this criticism is about 15% unfair given that Java did actually introduce some new concepts to mainstream programming but implemented them in the VM rather than the compiler, but it has really failed to keep up with the times).
At this point if I were using the JVM, it would most likely be to make use of some hypothetical damn good libraries. In that case, as I'd be gluing together things that are already typed, I'd use whatever dynamic language seemed prudent. The Java type system is an everpresent fact of life on the JVM, and I'm now of the opinion that trying to use a second type abstraction concurrently is foolish (especially if one wants to run their code on anything other than Hotspot). I think Clojure is an amazing piece of work, and would still be using it, but its lack of importance on typed data structures really kills my ability to reason while developing new abstractions (the lack of well-supported algebraic data types and pattern matching especially). Taken together, those last two points imply that a statically typed JVM language has to utterly commit itself to the Java type system. If I absolutely needed to write a library on the JVM, I would look into and most likely go with Ceylon/Kotlin (or Gosu if they ever actually did a source release), but failing those probably write java-in-kawa for the straightforward class definitions with macros to ease the pain.
In any case, I'd be damn certain of exactly what I was writing beforehand. The Java ecosystem is absolute garbage for prototyping.
Macros in Scala are primarily of interest for metaprogramming; it's a fairly natural direction for Scala to take, given that Scala has always positioned itself as a language that supports internal DSLs.
Similarly, in syntactically richer languages, macros could add syntactic constructs that are not akin to function application. With sufficiently powerful macros, you can add, for example, new infix operators, a new form of switch/case or a new way to declare variables.
myObj explode 10 times
which translates into myObk.explode.10.times()
Through the magic of implicits, you can make any builtin type auto-cast to your wrapper type, so there really is no need for syntactic macros - scala is already DSL-enabled.