That isn't the individual tools showing concurrency - they are running concurrently due to the way the OS manages processes and pipelines.
The overall task has multiple things running concurrently but it doesn't have to[1] and the individual components are doing no concurrency of their own. It has the same effect in many cases because of the buffering built into how pipes are handled, for instance passing the output of gzip through gzip through gzip will happily use most of three cores (if that much CPU time is free at that moment) but try that with commands that need to block such as invocations of sort for example and you'll see that break down. One sort command in your pipeline will tie the whole lot to not scaling much beyond one core[2]. Also pipes and other trickery like xargs/parallel don't help if the task is something like "grep over this large file" - that will only scale over multiple cores at all if your implementation of grep supports a multi-threaded search (and your data is in cache or otherwise in RAM so the process isn't IO-bound).
[1] it could queue each and spool the output between to temporary storage, it is so chose
[2] note that some implementations of sort, such as the GNU version seen in most (all?) linux distributions, do support their own multi-core use