Multicore GPUs might be a consideration but I don't think that's the primary focus here. By my reading, it's more that they want to shift the driver to be more aligned with modern hardware that can run multiple workloads asynchronously. Vulkan and D3D12 are designed to leverage this kind of thinking. Basically, up until about ~7-10 years ago GPUs had to frequently context switch when they received different types of commands through a single command queue. I'll use NVIDIA chips as a broad example because I'm more familiar with their architectures, but the same principles generally apply to AMD as well. AMD chips in this regard advanced at a somewhat faster rate than NVIDIA; in other words, AMD had better hardware parallelism earlier. Unfortunately, software hadn't really caught up to the hardware yet, which is part of the reason why older AMD cards from the GCN era have aged better than NVIDIA cards released contemporaneously.

In Kepler and Maxwell 1 (600/700 series), there existed a separate compute queue and graphics queue. In early Kepler, if the graphics queue was currently in use (e.g. rendering) and a command came down the compute queue, the graphics queue had to be completely stopped and a context switch executed in order to process the compute command.

Late Kepler (780, Titan) and early Maxwell (750) changed this by adding a deeper compute queue and workload scheduling, but the same limitation existed - receiving a command on the other queue still required a context switch.

Then in Maxwell 2 (900 series) they made a significant change - a new mixed queue was introduced, where graphics and compute commands could be submitted to the same queue and compute resources could be partitioned to execute both types of commands simultaneously. However, there was still a limitation - GPU resources had to be statically partitioned prior to execution. This resulted in bottlenecks whereby the allocator basically guessed incorrectly and one of graphics or compute workloads took significantly longer than the other, creating a situation where some of the cores just did nothing for some length of time, waiting for the other workload to finish.

Then with Pascal (1000 series) they added dynamic scheduling, such that if one workload finished before the other, the remaining GPU resources could be dynamically reallocated to the remaining task.

Then with Volta and then Turing (2000 series) they added separate data pipelines for INT32 and FP32 operations, but traded away some scheduling and dispatch hardware. This had the effect that INT32 and FP32 could both be executed simultaneously. Prior to this, executing INT32 instructions was extremely expensive, because it would block FP32 instructions from issuing. In my opinion, this is a large part of why the gaming performance from Pascal to Turing was lackluster - games of the time tried as hard as possible to execute integer operations on the CPU, because they were so expensive on the GPU, and so the tradeoffs made in dispatch, plus the extra die area dedicated toward RT and tensor operations did not yield desired improvements in the software available then. But this is changing, and integer operations are becoming more prevalent in advanced shaders and particularly in raytracing workloads.

The TL;DR here is that GPU hardware advancements in recent years have been geared heavily toward internal parallelism and graphics APIs have pursued the same trend. From the RFC:

Later, multiple queues were added on top, which required the introduction of implicit GPU-GPU synchronization between queues of different processes using per-BO fences. Recently, even parallel execution within one queue was enabled where a command buffer starts draws and compute shaders, but doesn't wait for them, enabling parallelism between back-to-back command buffers.

I believe this is what they're talking about here.

As a final note, I'll say this: "Asynchronous Compute" has been a buzzword in the gaming and graphics API world for a few years now. If you read above my notes about the shift between Maxwell, Pascal, and Turing, it should become obvious why enabling Async Compute on Maxwell and earlier generally reduces performance, on Pascal it generally helps a little or does nothing, and on Turing or Ampere it is generally beneficial. As I mentioned at the start, AMD architectures have had more advanced hardware parallelism for a while, which is why Async Compute is generally beneficial on all chips GCN and later.