Database_Nova , thanks for the feedback. It helped me clarify the points you were asking about - I appreciate it. See the updated write-up.
Yes, parallel queries is the same as parallel processing done by SQL Server. You submit a query and if it is "too expensive" from optimizer point of view AND if it qualifies for parallel processing, SQL Server will break up the work among multiple threads. As a simple example, let's say you submit a query against a huge table and want to get all rows and perform aggregation select sum (sale_amount) from InternetSalesTbl. SQL Server could take that clustered index scan and split it among 8 threads, with each of the threads scanning a part of the table , in parallel with the other threads. That way you get the work done ideally 8 times faster (not always the reality because there is overhead to parallelism and because distribution of the data among all threads may not be an even 1/8 of the table - it is driven by statistics). The same MicrosoftDoc I quoted above provides an example for you to look at.
Yes, good point- system sessions (those created by SQL Server for internal operations like checkpoint, lazy writer, and many others) are not invoked by an external client application. In other words no external connection was open to SQL Server to get those started. Therefore your statement about 1:0 mapping is correct - a session exists, but no corresponding connection to it. Thanks for reminding me of this scenario. I have now captured it in the write up above. Thanks for helping make this write up better for the benefits of many.
Your query example is accurate, but the older sysprocesses system view provides a much better insight as to what those system sessions are doing. Here is a query to help visualize that
select spid, kpid, lastwaittype, login_time
from sysprocesses
where spid < 50