Knowing a bit of both Smalltalk and Lisp I have to disagree with you.
First, how easily integrated your code is with some other code depends on how much of underlying semantics the two pieces of code share. Both Smalltalk and Lisp are quite minimalist in terms of semantics, which means that everything you write in them will share large part of its semantics with any other code. At some level in Lisps all code is full of conses and in Smalltalk is just objects with messages (I'm over-simplifying ofc, but you get the idea). I know that "at some level" all code is just a list of instructions for CPU - but you get to this common denominator much quicker in Lisp and Smalltalk than in most other programming languages, which makes programs written in both of them more composable, not less.
Second, how easy a DSL is to understand depends on the "L" - after all it's a language, and you most certainly can create completely undecipherable language. That's not a problem with DSLs, however. There are many bad DSLs, but there are also many pretty and readable ones. Some examples I just thought of: http://docs.racket-lang.org/reference/Command-Line_Parsing.h... in Racket and http://pharobooks.gforge.inria.fr/PharoByExampleTwo-Eng/late... in Pharo. They are both readable and easily composable, of course only if you know the semantics of underlying language, but even this is easier because there are so few of them in both languages.
Third, metaprogramming, meta-object protocols, macros and so on are indeed easily abused and you should avoid using them if a simpler abstraction will suffice. But there's some point where you find yourself repeating the same patterns over and over, despite already using all the lower level abstractions. This is where you should use one of higher level ones - contrary to what you say it can make overall readability of the code better. For example, Django ORM does quite a bit of magic behind the scenes - but this means that all this magic is gathered in one place instead of being scattered through all the models in your project. And it makes simple cases (which are probably a majority of cases anyway) much shorter than they would be otherwise - and being shorter (not on its own, see http://weblog.raganwald.com/2007/12/golf-is-good-program-spo...) improves readability.
In short, the problem is as it has always been: bad (domain) languages, unnecessary abstractions and too rich base languages. Next time you have an opportunity to design a good DSL, or fitting high-level abstraction or macros library, just do so. Just try it on your own quite a few times before introducing some of these techniques into production system or team environment.
Third, metaprogramming, meta-object protocols, macros and so on are indeed easily abused and you should avoid using them if a simpler abstraction will suffice.
First, how easily integrated your code is with some other code depends on how much of underlying semantics the two pieces of code share. Both Smalltalk and Lisp are quite minimalist in terms of semantics, which means that everything you write in them will share large part of its semantics with any other code. At some level in Lisps all code is full of conses and in Smalltalk is just objects with messages (I'm over-simplifying ofc, but you get the idea). I know that "at some level" all code is just a list of instructions for CPU - but you get to this common denominator much quicker in Lisp and Smalltalk than in most other programming languages, which makes programs written in both of them more composable, not less.
Second, how easy a DSL is to understand depends on the "L" - after all it's a language, and you most certainly can create completely undecipherable language. That's not a problem with DSLs, however. There are many bad DSLs, but there are also many pretty and readable ones. Some examples I just thought of: http://docs.racket-lang.org/reference/Command-Line_Parsing.h... in Racket and http://pharobooks.gforge.inria.fr/PharoByExampleTwo-Eng/late... in Pharo. They are both readable and easily composable, of course only if you know the semantics of underlying language, but even this is easier because there are so few of them in both languages.
Third, metaprogramming, meta-object protocols, macros and so on are indeed easily abused and you should avoid using them if a simpler abstraction will suffice. But there's some point where you find yourself repeating the same patterns over and over, despite already using all the lower level abstractions. This is where you should use one of higher level ones - contrary to what you say it can make overall readability of the code better. For example, Django ORM does quite a bit of magic behind the scenes - but this means that all this magic is gathered in one place instead of being scattered through all the models in your project. And it makes simple cases (which are probably a majority of cases anyway) much shorter than they would be otherwise - and being shorter (not on its own, see http://weblog.raganwald.com/2007/12/golf-is-good-program-spo...) improves readability.
In short, the problem is as it has always been: bad (domain) languages, unnecessary abstractions and too rich base languages. Next time you have an opportunity to design a good DSL, or fitting high-level abstraction or macros library, just do so. Just try it on your own quite a few times before introducing some of these techniques into production system or team environment.