The only thing that makes programs easy to deploy is the popularity of the language/environment they're written for. If the language you're using is popular enough that you can download the implementation using your system's package manager, deployment is easy. If not, it's harder.
And for any language that's popular now, there was a time that it wasn't yet popular, and deployment was a pain.
So I think you have it backwards: Lisp is not unpopular because it's hard to deploy; it's hard to deploy because it's never cracked the popularity threshold.
The old joke with Common Lisp used to be if you've developed a program for one version of Common Lisp, you've developed a program for one version of Common Lisp.
Lisp is notoriously hard to deploy. Code is not portable between different lisp implementations. Apple's ATG ended up axing many projects because they had so much trouble moving their lisp from 680x0 to PowerPC.
The fact you talk about "your system's package manager" ignores my point -- I'm not saying Lisp is especially hard to deploy to servers (although it is -- but this is, as you say, a popularity issue; and it would be far worse if the world of servers hadn't converged on a small number of very similar platforms). I'm saying it's hard to deploy to desktops and mobile, which is where most of the "useful" programs people might want to write still live.
A huge part of Lisp's problem is fragmentation. Which Lisp? Aside from fragmentation in Common Lisp itself, there's all the not-quite-Lisps around, ranging from Arc to Scheme to Clojure to sheesh-I-really-have-no-idea. And of course this is because once you start coding in Lisp there's an overwhelming urge to abstract away difficult things in your own clever way, perhaps even hacking the language itself, and pretty soon your little world is utterly unique.
Another great, simple language in the exact same boat is Forth.
This is only telling half the story. It is perfectly true for, say, Python (still a pain to deploy on Windows, or at least it was the last time I tried), but newer languages that are less popular like Go do not have this problem. Even Rust, a language that is only in alpha, does not have this problem!
Why is this? It's because they can live in, and interact with, the common linking and loading ecosystem that the rest of the world lives in: the C ABI. If you can link your output into something that respects the C ABI, you can deploy it[1].
Common Lisp implementations could immediately solve their deployment problem by living in this ABI. So far, the only one that has done so is ECL (which is an excellent project).
[1] A few alternatives exist. The Java and .NET ecosystems are also viable link targets (as I think Clojure has proved).
Well, sure, if all your programs need is the OS and common libraries, deployment is easy.
But this only restates the point. It's easy because those things are popular. Try deploying an executable that requires a shared library that you can't download with your package manager, and you're pretty much back into the same pain.
Using the C ABI helps if you want to link against other code that uses it, though it isn't strictly necessary (pretty much all these language implementations have foreign call mechanisms). But this is a development issue, not a deployment issue.
ECL does make it convenient to build standalone executables, but most CL implementations can also do this.
And for any language that's popular now, there was a time that it wasn't yet popular, and deployment was a pain.
So I think you have it backwards: Lisp is not unpopular because it's hard to deploy; it's hard to deploy because it's never cracked the popularity threshold.