How do these lub’s affect performance in practice? IIRC, each of them creates two threads and uses some synchronizations between them.

The performance depends a lot on the implementation of unamb and lub and their susceptibility to compiler optimization. The most naive implementation I know of works as you mentioned: each unamb starts two threads, with an MVar to coordinate them. However, the threads can be avoided when (a) either argument is already evaluated to a non-⊥ form or (b) either argument is known to be ⊥ (e.g., typically an error of some sort, including evaluating undefined or a failed pattern-match). In other words,

a ⊔ ⊥ ≡ a
⊥ ⊔ b ≡ b
 
a `unamb` ⊥ ≡ a
⊥ `unamb` b ≡ b
 
a `unamb` b ≡ a  if  a ≠ ⊥
a `unamb` b ≡ b  if  b ≠ ⊥

All with the proviso the preconditions of unamb or lub are satisfied.

I’m more interested in the soundness and usefulness of uses of lub than its performance right now. Once there are compelling demonstrations of both, then there will be enough motivation to make high-performance implementations. Great performance might require some hacking inside the language run-time system. This same evolution occurred for lazy evaluation.

Are there cases where the non-strictness would outperform the performance penalty?

Yes, since non-strictness sometimes replaces non-termination with termination — a pretty impressive speed-up.

Seriously, though, like laziness, lub-based programming is about correctness, simple & rigorous reasoning, and modularity, as well as performance.

Cheers! =)