@Robert, Thats an interesting semantics question. Its true Pub/Sub paradigm is designed to write loosely coupled applications. But the glue still needs to be specified somewhere - for eg, a common queue name, topic subscription on the queue managed on the broker, etc.
On this specific question on DMQ and TTL, historically, the TTL value was provided by the publisher. You can argue that DMQ violates this constraint - publisher meant for message to be unavailable for consumption after N milli-seconds, but by expiring the message over to DMQ its available forever. So, allowing publisher to also control if the messages should be expired to DMQ makes sense.
This brings another question - is the same behavior right when TTL is set by the infrastructure (on the Queue) and not by publisher. My take is - yes, the behavior is uniform and backward compatible.
As per the default value being False, Solace decides on the default values based on common use-cases and feedback from the field. In older releases, there was a single DMQ per VPN, having this flag True for all TTL enabled messages would fill DMQ with potentially unwanted messages and prevent other queues from expiring to DMQ. Obviously, there is a wide array of use-cases and usages and irrespective of what we pick, its unlikely to be universally acceptable 
When messages are expired to DMQ, they are intentionally prevented from expiring again (its called Dead msg Queue for a reason :-)).
Here is Larry David’s (Seinfeld) take on DMQ for funs sake: https://www.youtube.com/watch?v=lBInjuIW6Lw