Use the language's existing resource-handling mechanism

Python-style with blocks get you most of the way there. Presumably bar and qux are tied together in some way, so write it as a context manager (or whatever your language has for safely opening and closing resources).

class Resource:
  def __enter__(self):
    bar()
  def __exit__(self, type, value, traceback):
    qux()

Now we can encapsulate the foo part in a conditional context manager

class IfTrue:
  def __init__(self, manager, condition):
    self.manager = manager if condition else None
  def __enter__(self):
    if self.manager:
      self.manager.__enter__()
  def __exit__(self, type, value, traceback):
    if self.manager:
      self.manager.__exit__(type, value, traceback)

Then, when you want to run this setup-teardown code,

with IfTrue(Resource(), foo):
  baz()

This couples the bar and qux parts, which, again, presumably are part of a setup-teardown procedure. The IfTrue context manager is also independent of everything else and can be used with another condition or resource type freely. If you find that this is something your language needs often, IfTrue is a good candidate for standard library inclusion.

You can use whatever tool your language uses for handling resources like files. In Python, that's with. In Ruby, you could just write a method that takes a block (like File.open does). In Java, your resource-allocation object can be AutoCloseable (hence compatible with the try-with-resources statement). In C++, you can use RAII to make the teardown run during your destructor.

Example in C++:

class Resource {
public:
  Resource() {
    bar()
  }
  ~Resource() {
    qux();
  }
};

void example() {
  // Note: std::optional is basically IfTrue already; it
  // runs the deallocation if the thing on the inside exists.
  std::optional<Resource> resource;
  if (foo) {
    resource = Resource();
  }
  baz();
  // resource implicitly goes out of scope and calls qux()...
}

The point is:

• Decouple the problem into two parts. We have a setup-teardown, and a condition.
• The setup-teardown pattern is something most languages already have, for dealing with file I/O and other resources. Leverage that.
• The condition can be added to the resource-management code, making a new resource that's implemented as just "resource plus condition".

Clearly, inside our hearts (or at least inside mine), what we all want is a table of code, that more explicitly expresses the relationships among parts of code:

(assuming what you want/need is as-if the condition is evaluated only once)

if (foo)

(*) imagine that this row has only 1 cell spanning both columns (i.e., rowspan = 2, but cannot do that with stackexchange's markdown, apparently)

Of course for a switch or a match you just add more columns. :-)

This is giving me goto flashbacks but here goes:

foo_case: if (foo) {
  bar()
}

baz()

continue foo_case {
  qux()
}

The use of labels and continue allows nesting.

Separate the testing of a condition from the blocks that use the outcome of the test. This is a form of pattern-matching, for matches that should proceed sequentially, and need not be exhaustive.

given (foo) {

    when (true) {
        bar();
    }

    baz();

    when (true) {
        qux();
    }

}

Internally this can be lowered to basic blocks that only test the condition once. For example, in SSA (where parameters are equivalent to phi nodes):

start() {
    t = test(foo);
    if (t) true1(); else always(end);
}

true1() {
    bar();
    always(true2);
}

always(return) {
    baz();
    return();
}

true2() {
    qux();
    end();
}

end() {
}

Similar to the suggestion of Python's with syntax, some functional programming is all you need:

withBarQux = \run -> {
    bar();
    run();
    qux();
};
withNothing = \run -> run();

(foo ? withBarQux : withNothing)(baz);

A programming language can help with this by providing withNothing as a builtin - it is the application operator, or if the pattern is expressed a bit differently, the identity function comes handy as well. Also allowing to pass code blocks to functions without explicit lambda expressions could make the syntax a bit nicer. With Scala's by-name parameters, this could look like

(foo ? withBarQux : withNothing) {
  baz();
}

(which is helpful when the baz() code is not already a function that you can pass).

What ways could a language include a DRY method to do this and how could this be optimized in assembly?

One way is to prefix each statement with something that decides whether to execute it or not. For example, in languages with short-circuiting operators, you could write something like:

foo && bar();
       baz();
foo && quux();

If foo is a long expression and/or has side effects, you could first store its result in a temporary variable:

bool f = foo;
f && bar();
     baz();
f && quux();

In assembly languages there is a direct way to optimize this on some CPU architectures. For example, a lot of 32-bit Arm instructions have some bits to tell whether to execute that instruction or ignore it based on the state of certain processor flags. On x86 you have the conditional move instructions. And in almost all CPU architectures, jump instructions can be conditional. As long as bar() and baz() in your example don't modify processor flags, then only a single compare instruction is necessary to evaluate foo to update the processor flags, and that can then be reused to conditionally execute the rest.