A lot of hardcore Lisp aficionados do the equivalent of a mathematician writing a "sketch of a proof" and saying "left as an exercise", without ever writing the details of the proof. It's occasionally aggravating when you pull in a library and discover that this is the case.
To be clear, there are many Lisp folks do not do this. Some go the full mile and implement something completely and robustly. Edi Weitz has been the canonical example in the community.
You might want simplicity, but users also want performance. So a complete solution will be performant, but simple.
You have one use case, but other users have others. A complete solution will work in as many use cases as possible given its constraints.
Scala's parser combinators are a good example of a complete solution. It offers the "elegant" solution of parser combinators. But it also offers an implementation of this using things like Packrat parsing that are extremely efficient.
The non-complete example of this is someone who writes a parser combinator library that is simple, but simply not performant for real world use. For example, you might write a simple version in Python, but not properly apply TCO and so your parser can't handle deeply nested structures because of a stack overflow.
---
With regards to owning code, I remember hearing that it took 9 years of the initial publication of quicksort for there to be a bugfree implementation of it. Even easy things can be tricky.
Well, comprehensive unit tests for a start...
That's exactly "too powerful for its own good". It's so easy to write a half-assed sketch of a library that nevertheless gives you some new powerful feature, that some people end there, and publish the sketch that was enough for their use case.
I actually think Quicklisp has helped. It's even easier to do (ql:quickload "foo-lib") than it is to write my own foo library.