Max productivity to the library implementor not to the integrator or maintainer. The number of hours I've spent inlining gross macros so I can debug them has poisoned me against all but the simplest application of them.
On the other hand, they should be most of the code if taking a DSL- or MOP-like approach. The people using those will be very familiar with the higher-level language. There's a solid, lower-level language underneath for when the VHLL's don't work out. The macros help there.
Second, unsubstantiated proclamations like "Overuse of them led to LISP code being hard to read" reinforce the previous point. Could you provide a clear reference where Lisp macros are considered "mistakes of history"? Clear references where overuse of Lisp macros turned out to be a problem?
I'm curious if you've ever used a Lisp development environment with facilities such as interactive macroexpanders or if you're just assuming things based on your (incomplete, suspect) understanding of the domain.
Capitalization isn't a deep signal.
There are lIsPs like Clojure that argue (> data functions macros). Although I mostly disagree (for example I love Racket macros), I understand and appreciate the sentiment. I have heard it from other people who have worked with a variety of LiSp code bases over the years. TL;DR: Any form of non-trivial DSL needs supporting materials like documentation and a simple, clear design.
Although it is nice to be able to expand macros, fully-expanded macro-generating macros are clear in approximately the same way as assembly language. It is impressive if you can navigate that, but even more impressive if can manage not to need to do so.
That's not really Lisp related. It's more like how the community likes to see code being written.
For example I would regularly make use of macros to provide more declarative syntax various programming concepts.
There are Lisp dialects which are light on macros and some which are using macros a lot more. For example the base language of Common Lisp already makes use of many macros by providing them to the user as part of the language (from DEFUN, DEFCLASS, ... INCF, upto LOOP).
Actually both versions are valid.
You seem to not know historical information about Lisp/LISP. While Common Lisp is spelled "Lisp" and more modern use is Lisp, historically LISP has been prevalent (and tons of Lisp dialects prefer the capitalized version, e.g. like "fooLISP" or "barLISP").
Second, you are concerned with superficial details people don't and should not care about. We're programmers, we care about the code and what you can do with it, not about whether some language is "properly" spelled in caps of mixed case.
Third, you are rude, which is worse than both of the above.
I learned about it from old books, often on AI, I could scrounge up when I didn't have the Internet or a computer. LISP as in LISt Processor. An acronym. Due to broken memory, I sometimes forget which term to use on stuff that's faded away. I end up about randomly using LISP or Lisp unless its Common Lisp where I usually see "Lisp" in write-ups.
So, good guess.
I don't think that's the case.
That poster your comment goes to claimed that there are types of macros which make debugging harder - not code reading.
Debugging code which makes use of macros is more complicated than code without. There is no doubt about it. One part of it is that debugging happens in a different place -> code transformations with side-effects are running in a compiler or with interpreters at runtime.