There's no single answer solution that is correct for all situations,
A procedural language is good for describing a procedure (quite common in a scripting environment: "Do this then this then this...").
Object-oriented languages are good for describing problem/application domains ("There's this thing and this and this...") - if you've got the time and budget to do the analysis needed to create such a domain description - if there's a particular problem immediately to hand it's a higher priority to solve that problem than to solve every other problem as well. They're implemented procedurally.
Declarative languages are good for specifying actual problem instances ("This is what I want done: do it for me."). They're typically implemented these days in an object-oriented fashion, with the object graph being used to model the syntax and semantics of the declarative language.
In the context of DSLs, the last category is starting to become better recognised and adopted - in no small part because they do require somewhat more computing power to implement (just as object orientated programming requires more than procedural programming) and so had to wait for interpreters and compilers to become fast enough (and/or machine code/bytecode/low-level source caches to become large enough). (Imperative DSLs do still exist for scripting purposes. But if your application is going to be scriptable, you will eventually want the scripting language to be computation-universal - so you might as well save yourself some trouble and just embed something like Python or Lua or some other well-designed language of the genre right from the start.)
But that kind of covers any significant application: the bit that prevents coding from being coding for its own sake is the job of constructing a language so that users can communicate their wants to the application and the application can communicate the results to the user: declarative DSLs are formal (i.e., machine-readable) instantiations of things that previously existed in piles of requirement specifications and job tickets and wireframes and back-of-the-envelope scribbles. (That's another thing about declarative languages: they're much more amenable to being processed in different ways for different purposes - diagramming, document generation, code generation, execution...)