Horrible as c++ might be in many respects, the elaborate and somewhat stereotyped syntax of the code some random person wrote does tell a story.
If the code uses the horrific "one big loop" convention, it's fairly easy at least to get that that is what's going on.
I've only occasionally scanned Lisp code but in my experience of this, it seems like the formatting of the code doesn't a clue about the programming idiom being used. Admittedly, part of this is that Lisp allows more and more powerful idioms. This part seems really cool by itself.
Despite that coolness, I think one has to admit there's a cost here, the cost of a large block of code not being graspable by an outsider.
Perhaps the subset of C++ used reveals something about the development team that wrote it I guess? But there are certainly analogous things in lisp. Is the code macro heavy or light? Was the developer trying to treat the language like an imperative language, or functional? Massive monolith functions, or many small almost mathematical functions? Comments, or no comments?
I think that C++ and Lisp might actually be relatively unique in that respect. You typically don't see much variety in Java (beyond "This code was clearly written by a C developer who wishes he could just use C for this", which comes through loud and clear sometimes), and even less in Python.
I learned Scheme over 20 years ago and it wasn't that hard to use it for small college projects. But that's different from being comfortable working with large code bases full of unfamiliar code.
Languages shouldn't be judged by how easy it is to write code, or read your own code, but rather how easy it is to jump into someone else's project and figure out what they did. The level of understanding should be enough to see security bugs when they screwed up.