Why do and then un-do?

The reason is that we've not yet found a better way of making fast general purpose processors.

The OOO (= out-of-order) approach with high-quality prediction (e.g. branch, value) to processor micro-architecture makes sense if you have to mask a lot of memory-access latency, which comes from data-dependent (= unpredictable) memory access. General purpose workloads have a lot of that. (If memory access patterns are more predictable, you'd probably run your workload on a GPU or TPU or DSP, or some other accelerator.) Compilers, whether ahead-of-time, or JIT, have not got enough information to schedule commands in a way that can mask memory latency the way an OOO scheduler inside a processor can. Stalling the pipeline because you are waiting for data to arrive from memory is disastrous for performance and to be avoided at all cost. Intel's Itanium was based on the premise that it is possible statically to schedule well enough, but that has been considered a failure for general workloads. Moreover, if you let a compiler schedule you need to have ISA extensions that allow you to communicate scheduling information to the processor which is not cost free (for example you may spend precious bits to encode scheduling order that you then cannot use for other things).

I suspect that the very last word has not been spoken in this discussion, but everything obvious to make dataflow competitive (and quite a lot more) has been tried, and failed.