I don't think it's the right language for every level of development. But I think it would be pretty well-suited for a lot of the stuff I do, which is largely data curation, routing, and filtering.
Sure, if it's good for what you commonly do than more power to you. Languages are tools and all that jazz, and you shouldn't be trying to nail screws in with a hammer. But for "expressivity" (Note:, there are a lot of definitions about what exactly it means for a language to "expressive", so pardon me if I'm using a different one here), I think I'm gonna have to say that in the vast majority of cases the human mind when thinking of a step by step process thinks in a way that is much more similar to a language like C++ with it's step and state focused paradigm than that of recursive functional languages. The proof of this can be observed simply by opening up a nearby cookbook, or by googling "instructions to do X" on google where X is anything that you want. I can almost assure you that the instructions you find there will be much more likely to be based around sequential steps with iteration than recursive calls.
mix butter
mix sugar
for(i = 0; i <3; i++)
crack egg[i]
put egg in bowl
beat egg into mixture
add sugar
add flour
mix
So while LISP's power let's it be extremely expressive in the small number of cases that I have to think in a way that fits it's paradigm, in the other 90% of cases a language like C++ is actually going to be closer to my thinking than LISP is. (If on the other hand you're talking about "expressivity"as a language's ability to say just what it needs to then yeah, it takes a lot more work to get C++ there than it does in LISP.
)
I think that's the underlying feeling that a lot of people have, and it's perfectly understandable and valid. But I think there's a reason why Lisp still beats other languages for expressivity, and that is the fact that it allows you to not actually
care how the machine is operating underneath. There are plenty of scenarios where you need to know
exactly how things are lined up in memory, exactly how much memory you're using, or if you're being optimal in cache usage, but I posit that those situations are actually far fewer than most developers think. Unless you're writing airplane navigation systems, medical monitoring devices, large-format printers with giant lamps on either side that can start fires in less than three seconds (guess which one I used to do), I don't think it actually matters all that much if your program runs a particular function in 200 milliseconds or 400 milliseconds.
The introduction to SICP has a line that says "Thus, programs must be written for people to read, and only incidentally for machines to execute," and I think that holds true today. So if I can express a program's actual point without a lot of jumping through bare metal hoops, that program is, all other things being equal, going to be easier for another person to pick up and look at.
I don't think Lisp is the end-all, be-all of languages. But I feel like the fact that modern languages keep pulling features from it implies that it's, at the very least, an incredibly useful object lesson into what a program should look like.