Understanding someone elses code is always a challenge. Outlawing custom abstractions in favour of a few very shallow ones doesnt seem like a convincing thechnical argument.
The problem is that LISP macros are extremely powerful. The DSLs you can design don't always neatly fit into a box and integrate seamlessly. They're leaky abstractions. You don't necessarily know what's a function or a macro. You don't necessarily know that a macro isn't doing lazy evaluation or redefining some operators you're familiar with.
Programming languages aren't just about coding, they're also about having a shared language that other people can understand. If you introduce 500 new syntactic forms that you designed yourself into your code, and newcomers have to look them all up to really understand what's going on, that makes it much harder for new people to onboard.
LISP loops minimalistic on the surface, but it's kind of a lie. In practice it's easy for it to become exactly the opposite of that.
In most lisps, few stray from the basic data structures, such that the data you can get is usable basically everywhere.
Contrasted with many Java libraries, where coding a library locks you in to said library.
Yes, a few have tried to keep interface compatibility with the core collections. I'd hope most do, nowadays. But that really just highlights that we are both talking of previous year's mistakes.
My hypothesis is it comes from novice attitudes in building everything as a masterpiece. As the community matures, things tend to stabilize.
The entire point of the Lisp Curse is that this is a social issue! Not a technical one. And, furthermore, what is a technical issue in another language can be pushed into being a social issue in a Lisp. And social issues are a lot more difficult to solve.
Compare this to something like Java + Spring Boot or Ruby on Rails or any other framework favoring configuration and convention over code. Where the explicit point is a social agreement on what a program looks like, which in turn allows everyone to hopefully focus on the actual business logic.
(Also: Sibling commenter already addressed the differences in abstraction power better than I would have.)
For instance, suppose that cheap and 100% effective sound-proofing were available and installed into every apartment by default (an example of (practically nonexistent) technology). Then unwanted noise from neighboring units wouldn't be a social problem.