How many Direct/Compute/Copy Queues are meaningful? DirectX 12 exposes command queues for either graphics (called "Direct"), compute or copy tasks. In terms of provided functionality, each one is a super-set of the following one. The specification states that command queues can be executed concurrently by the device.  However, the API does not limit the number of command queues in any way (at least I am not aware any limitation).

Apparently, different vendors handle this very different:


Intel states in a recent presentation (slide 23) that currently their GPUs are not able to handle Graphics &amp; Compute in parallel and that the copy engine has a weak throughput. They advise against the use of multiple graphics/compute queues.
AMD started long time ago to advertise the use of queues / "asynchronous shaders" starting with Mantle and the current gen consoles. There are also some developers (example) that confirm significant performance gains by executing compute and graphics tasks in parallel.
There has been recently some fuss about Nvidia not supporting asynchronous shader in the hardware: Using separate Graphics and Compute queue at once seems to make things slower which indicates driver emulation. Parallel copy operations, on the other hand, have been supported by CUDA for a very long time, which makes it clear that the DMA engine can work independently.


Is there any way to decide at runtime if it is meaningful to commit CommandLists to multiple CommandQueues instead of a single one? (given that former case does not involve much engineering-overhead)

While I can easily see how it is useful to perform memory operations parallel to compute/graphics operations, it strikes me as unnecessarily complicated to run multiple compute and graphics processes in parallel (unless there is no major perf. benefit).
It is also not clear to me, how this can lead to significantly better performance anyways; except for pathological cases where many small sequential tasks are not able to generate enough GPU load.
Ship your application with a benchmarking sequence testing the actual platform. (Possible answer for many questions I guess...)

I suspect the performance is highly dependent on how you use the hardware. Since the hardware is unlikely to somehow instrument your application backwards, telling you what to do, I´d go with whatever looks good in your design.


  "...command queues can be executed concurrently by the device..."


Keyword is CAN. I see no reason why any vendor would screw this up. In the end it is the platform provider (Intel/AMD/Nvidia) who is responsible of making you a good enough driver for you not to consider switching vendor. If they do have a "know issue" with this functionality (which by the way has no functional meaning, only performance) then they should also solve it using what they know. I mean for crying out loud, the fallback is something they have already implemented; synchrounous execution. 

Hardware is enough voodoo as it is for us developers.