What a strange critique point. Do you have to pay in gold for each dependency?
LLVM is pretty close to internally self contained as it DIY or vendors things in traditional C++ fashion (has optional deps on zlib and ncurses), especially if you use libc++ with it. However it is enormous and continually in flux. Building on LLVM also means picking up C++-like semantics regarding aliasing/undef/poison/freeze which are themselves somewhat in flux.
So in this case if PicoLisp emitted aarch64/x64 directly I'd consider that smaller/simpler than depending on LLVM, despite the increase in complexity in PicoLisp's own codebase from DIY'ing the machine code generation.
Fundamentally moving a load of complexity into a library can be a win but is not intrinsically cheaper than keeping it internal. You don't pay for it in gold - you move dev time and failure modes around, possibly for a net win and possibly for a net loss.
I'm curious about this assertation. I've also heard that "do one thing and do it well" is a desirable goal and one should offload tasks to other pieces that specialize in that task (e.g. don't write your own crypto, use existing libraries), is there something that makes a programming language different?
In the context of programming languages, dependencies are a property of a programming language implementation. LLVM is not a small system, yet PicoLisp is a small language, which is why it might be considered a heavy dependency. There are scenarios like embedded where having a tiny implementation with little dependency pays off.
Ordinary programs can be very easily maintained by using only the language's standard library, as standard library is often maintained substantially longer than many third-party libraries.