IMO the author is mixed up on his definitions for concurrency.
replies(4):
> Asynchrony: the possibility for tasks to run out of order and still be correct.
> Concurrency: the ability of a system to progress multiple tasks at a time, be it via parallelism or task switching.
> Parallelism: the ability of a system to execute more than one task simultaneously at the physical level.
Asynchrony means things happen out of order, interleaved, interrupted, preempted, etc. but could still be just one thing at a time sequentially.
Parallelism means the physical time spent is less that the sum of the total time spent because things happen simultaneously.
in other contexts these words don't describe disjoint sets of things so it's important to clearly define your terms when talking about software.
Therefore I think this definition makes the most sense in practical terms. Defining concurrency as the superset is a useful construct because you have to deal with the same issues in both cases. And differentiating asynchrony and parallelism makes sense because it changes the trade-off of latency and energy consumption (if the bandwidth is fixed).
In ecosystems with good distributed system stories, what this looks like in practice is that concurrency is your (the application developers') problem, and parallelism is the scheduler designer's problem.