"rather than looking like templated design patterns" - that is, the code goes straight to the point instead of being littered with incidental noise and ceremony? How that could possibly be a bad thing? Well, in certain software development subcultures ceremony might be a norm, but not in general.
From what I have seen, code that "goes straight to the point" is usually poorly thought out, is unmaintanable, has bugs, is difficult to extend to new use-cases, and the developer who wrote it is long gone.
No, it's the opposite - it doesn't have to drag around pointless layers of unused abstractions, and all the bugs that are there are bugs of subject matter, not of surrounding boilerplate. Such code minimizes the surface area and degrees of freedom, hence not leaving space for bugs.
The more I program, the more I'm convinced that - unless you've coded identical software many times before - code needs to grow organically and stay as focused and close to the problem as possible. Abstractions should follow naturally and be done "just in time". If they're needed, they have to be written either way, and you're not saving time by writing them up front (focused code is easy to refactor).
Of course with experience, you learn that some patterns of change are likely to occur, or that some touches of abstractions here and there are very beneficial. But beyond that, I feel the best way is to write simplest code possible, wait for it to be needed elsewhere, and then DRY up semantics.
I liked the posts of Casey Muratori, which explain roughly this mindset, calling it "semantic compression" and "compression-oriented programming": https://mollyrocket.com/casey/stream_0019.html.
Best practices, patterns, idioms are all important no matter what language. Lisp is not special in this regard (although, I admit, Lisp developers may stick around a bit longer).
In reality, yes, at least because of two differences:
1. Lisp is a significantly more powerful language, compared to most non-Lisp languages. Thus, many patterns and practices that are needed in other languages, are simply not needed at all in Lisp, or become far simpler.
2. Lisp is a "programmable programming language" where code is a "first class citizen" and can be manipulated as well as any other kind of data such as numbers. This opens a very different approach to programming, with its own, different "best practices".
Best practices, patterns and idioms are all tools, not religious symbols. If you treat them as the latter, you end up with things like JavaScript one-line projects that have 1kb worth of grunt/gulp/webpack config files, or with HelloWorldFactoryLightweightBridgeBuilderAbstractFacade in Java.
