Of course we need general-purpose, extensible languages. We also need motherhood and apple pie. But multi-paradigm languages are usually mistakes. They aim to give you the best of multiple worlds but frequently wind up giving you the worst.
We saw this with C++, which was supposed to be a structured / OO hybrid. The trouble was, the mismatch between the strucutred world and the OO world created huge complexity, starting with functions that might or might not be virtual. Non-virtual destructors anyone? Not to mention the fact that structured programming doesn't use GC, but proper OO programming requires it. See http://www.ipipan.gda.pl/~marek/objects/faq/oo-faq-S-3.12.ht... for the reasons why.
The problems get even bigger when you try to hybridise functional and OO paradigms:
* In OO the core concept is the mutable object. An object has an identity that persists as it mutates, and you can distinguish between two otherwise identical objects because they have different identities. Hence the distinction in all OO languages between reference equality (two references pointing at the same object) and object equality (two distinct objects that are equal in all their fields).
* In the functional paradigm, on the other hand, there are only values. Asking if two strings are the same object, or two employee records, is as meaningless as asking if two "3" values are the same object. Values are also immutable, so the idea of changing a string or employee value is as meaningless as changing "3" to be "4".
So when you create a hybrid functional/OO language you must deal with this impedance mismatch. If objects are mutable then the order of execution matters, and you have to trust the programmer to get the data flow and control flow to agree, thereby losing the big advantages of the functional paradigm. If objects are not mutable then you don't have an OO programming language.
Finally, I do not believe that "Any sufficiently large program will have parts that are expressed best in different paradigms". Claims that some domain is best expressed in one particular paradigm always seem to end up with statements of the form "Yes, but I want to do this my way, and your paradigm makes me do it your way". Sure, if you try to write Haskell in an OO way you are in for a world of pain, but that just means that when using a functional language you should architect your application in a functional way. And similarly for an OO language of course.
I spent a long time in the OO world, and I've used the best OO language ever designed (Eiffel). I moved to Haskell, and have become convinced that for most general purpose programming the functional paradigm is superior to OO. (The exceptions are in hard real-time and resource-bound environments). And the reason is that Backus was right.