It didn't have macros because it was intended for the ho-hum enterprise programmer of the time, who, the thought was, would not know what to do with them.
Instead, they re-invented all those things badly (e.g. through gobs of XML and ugly reflection based metaprogramming).
The adoption cycle for even the simplest of Syntactical features when it comes to Java enterprise is >10+ years. In some companies its never.
The saddest part isn't even that. The sad part is a whole generation of programmers have been raised, and turned to be architect astronauts without ever using something like a lambda or a closure.
The only hope for programming as a craft now is hoping Oracle kills Java(even if by mistake), and then some thing like Perl 6 comes along to replace it.
I am aware that when I say this, I am basing my opinion on a sample size of two...
Macros, unlike generics are super easy to implement, so there is no reason not implement them, unless you specifically don't want to implement them.
Java didn't have macros because no one wanted the kind of dialect that macros allow, ie. re-learning a language every time you change company.
C macros are entirely different in use from Lisp macros. C macros are written in a text substitution language that knows virtually nothing about C, whereas Lisp macros are written in Lisp and operate on regular Lisp data structures. Even trivial things are very difficult to get right with C macros, whereas very complicated things are often elegant and simple with Lisp macros. It's an entirely different experience. They're not at all comparable.
C programmers learn to fear macros because C macros have a lot of problems. Few of those carry over to Lisp macros.
Attributes/annotations, compiler plugins, expression trees and aspects take the role of macros.
People haven't really given up on the idea of building out functionality for specific portions of their codebase (and we really shouldn't) we've just seemingly exchanged one very powerful solution for a sea of different tools.