Sorry, but that's plain wrong. "If they don't get it, the explanation is wrong" is already a stupid sentence (it's misused as an excuse for lazy and sloppy people far too often), but at least right to some degree - wrong teaching can do a lot of wrong for language learning. Think of the silly way Latin usually is teached - without actually speaking it, giving the reason that it's a dead language and so no need to speak it - but that way people often don't "get it", because like me they _think_ in the language they are using and a language without talking blocks this way to use it. But "they don't get it, so the tool is at fault" is just plain silly - it's not Smalltalks fault as a language or environment that people don't teach it right.
Programming language knowledge doesn't fall out of trees. It's an art that you need to master - and there is a lot of work to be done before one can decide wether a language is the right or the wrong tool for the job. For me there were several languages I used quite a lot where I early on decided that they are not the right tools for me. Mostly had to do with aesthetics. So I don't object to people saying that some language wasn't done for them. But saying a language failed because people don't "get it" is silly. People failed. Either by teaching it or by learning it. Languages are tools, tools don't fail. Oh, and tools don't have a message. They are tools. They might not be the right tool for the job - but if you say "language X isn't the right tool for job Y" be prepared for several other programmers popping up and saying the opposite. Just because they are solving exactly your problem in exactly the language you said wasn't fit for the job. People told me that Python as an interpreted language isn't fit for distributed file system programming. I objected and wrote one. There are TCP/IP stacks out there written in pure Lisp. People write games using Lisp - and I am not talking about oldfashioned stuff here! There are distributed systems written in Smalltalk. Telecom switches programmed in Lisp or some in Erlang (mix of functional and declarative programming language - two paradigms where people are fast to tell you that they are not usefull for real world problems). I've seen device drivers written in Smalltalk - if the system is designed for Smalltalk, that's not uncommon.
I've heard this "language X is at fault" about far too many languages before. Smalltalk. Comon Lisp. Scheme. Haskell. Clean. ML in it's manyfold variations. Prolog. Weird enough, if you do dig a bit through google, you will find many success stories for those languages and for real world problems. Ok, Haskell is a bit handicapped there - it is the only language where even I failed in "getting it". I don't blame the language, though, but much more my deficits in knowledge about the needed abstractions.
So in my experience people only pull the "if they don't get it, it's wrong" card when they themselves didn't "get it". And try to explain that fact by the inapproprietness of the tool instead looking for the real reasons. The fact that you allways hammer your thumb instead of the nail isn't an indication that the tool named "hammer" failed. It's just an indication of your manual imperfectness :-)