The only algorithms that do not care about memory latency are the digital signal processing algorithms and the like (which include things like video/audio compression and decompression), where there is a continuous stream of incoming data, which must be processed. When you have a continuous stream of input data, you do not need a von Neumann architecture. The execution units could be organized in a systolic array or the like, through which data flows continuously.
Otherwise, whenever you have to read a previously unused memory location from an address that is not predictable by the hardware prefetcher, you must pay the latency penalty.
There are only 2 ways to hide the memory latency, by doing something else while you must wait the arrival of data. You can either execute instructions taken from elsewhere from the current thread, which is OoO and which requires a lot of complex hardware to find which instructions may be executed, or you can use either fine-grained multi-threading or simultaneous multi-threading, where either the programmer or the compiler have taken care to prepare a lot of independent concurrent threads, so that the hardware may execute any instructions from a thread that is not the current one, without having to search and analyze the instructions, to find their dependencies at run-time.
Because this is much easier for programmers and for compilers, OoO is preferred for CPUs. Where the cost per core must be minimized, FGMT or SMT with a very large number of threads is preferred, like in GPUs.
In the parent article it is said that they will not use OoO, but nothing is said about multi-threading. If neither OoO nor FGMT/SMT are used, the result is a special-purpose processor, not a general-purpose processor, i.e. a processor whose use is restricted to DSP-like algorithms, because otherwise its execution units would stay idle almost all the time.
I have browsed briefly through the documentation of the programming language mentioned in the announcement, but it does not appear to have many features relevant for concurrent programming, not even at the level of the Occam language, which was used for Transputers.
The only unusual feature that I see, is a Fork/Drop thing, which works exactly like reference counts, except that instead of passing references to an object, copies to that object are passed, which is an optimization that may be useful in a concurrent program, but it is something that can be done by a compiler, without being visible in the programming language.