There's a lot of work needed on the CPU to set up a frame for the GPU, and a good chunk of that work is inside the graphics driver. Prior to DX12 / Vulkan, that graphics driver work was essentially forced to be single-threaded by the design of the API.
The hope is that DX12 / Vulkan lift that restriction, allowing driver work to be performed in parallel on multiple CPU threads within a frame. This will enable more efficient use of multicore CPUs, allowing game engines to push more complex scenes without becoming CPU-bound. That's the hope—whether it will be realized in practice is something we'll have to wait to see over the next few years.
To elaborate a bit: the output of a game engine renderer is a stream of DX/GL API calls that describe the sequence of operations to render a frame. However, there's a great distance between the stream of API calls and the actual binary command buffers that the GPU hardware consumes. The driver has to "compile" the API calls into the GPU's machine language, so to speak. That isn't a trivial process—it involves a lot of translation of API concepts into low-level hardware realities, validation to make sure the GPU is never set into an invalid state, wrangling memory allocations and data, tracking state changes to issue the correct low-level commands, and so on and on. The graphics driver is responsible for all this stuff.
In DX11 / GL4 and earlier APIs, this work is typically done by a single driver thread. Even if you call the API from multiple threads (which you can do using DX11 deferred command lists, for example), it just adds some work to a queue for the driver thread to chew through later. One big reason for this is the state tracking I mentioned before. Many of the hardware-level GPU configuration details require knowledge of the current graphics pipeline state, so there's no good way to break up the command list into chunks that can be processed in parallel—each chunk would have to know exactly what state it should start with, even though the previous chunk hasn't been processed yet.
That's one of the big things that changed in DX12 / Vulkan. For one thing, they incorporate almost all the graphics pipeline state into one object, and for another (at least in DX12) when you start creating a command list you must provide an initial pipeline state; the state isn't inherited from one command list to the next. In principle, this allows the driver not to have to know anything about previous command lists before it can start compiling—and that in turn allows the application to break up its rendering into parallelizable chunks, producing fully-compiled command lists, which can then be concatenated together and sent to the GPU with a minimum of fuss.
Of course, there are many other changes in the new APIs, but as far as multithreading goes, that's the most important part.