Concurrent requests not running in parallel
Think back to the bad old days when everyone's computer had a single CPU with just one core. If you ran a program that took 2 minutes on its own at the same time as another one that took 2 minutes on its own then both of them combined might take 4 minutes. There's only so many CPU cycles to go around after all and the two programs would be competing for resources. The same thing can happen in SQL Server if you throw too much work at it relative to your server size or if you get unlucky.

Based on your description of the problem, the most likely explanation is that session 1 and session 3 are running at MAXDOP 1 and they end up on the same CPU core. Session 2 is on a different CPU core. That could be why performance degrades when you run sessions 1 and 3 at the same time but running 1 and 2 at the same time leads to no degradation. To validate that, the wait type that you want to look for is SOS_SCHEDULER_YIELD. While the queries are running, you can also use the sys.dm_exec_requests DMV:

SELECT session_id, scheduler_id
FROM sys.dm_exec_requests;


If your two sessions end up on the same scheduler_id (a scheduler maps back to a logical core) then it's reasonable to expect that both sessions will take twice as long as they did when you were just running one query at a time. This is a bit more complicated if you have hyperthreading enabled and exposed to SQL Server, but the same kind of behavior can be observed. You would want to look at sys.dm_os_schedulers as well because you could see a similar degradation on different schedulers if those schedules are on the same physical core.

If you want to get into the details for scheduling, you could start by reading this blog post. A small quote:


  Scheduling assignment starts at the NUMA node level.  The basic
  algorithm is a round robin assignment for new connections.    As each
  NEW connection arrives it is assigned to a scheduler based on round
  robin, NUMA node connection assignment.


If your server has NUMA nodes that consist of just one scheduler then you could easily get yourself into a situation where queries get doubled up unnecessarily. The fix would be to change your NUMA configuration or to run your queries in different sessions until you get the desired behavior.