Part of parallel execution plan has serial portion
In answer to the question being asked (why is this portion of the query serial), I would ask another question: what would you gain from that part of the query being parallel?

Zooming in a little on one of the small serial portions of the plan that you mentioned:



There is only one row coming out of the "Merge Interval" operator.  Having that one row flow in to a parallel nested loops join would result in essentially the same behavior as the current plan: a serial nested loops join (with the added negative repercussion of there being unnecessary thread reservations).

There will be at most 2 rows coming out of the "Merge Interval" operator, depending on the specific values of the parameters being used in the query (manifested as the separate "Constant Scan" operators see this question and answer for a general explanation of what's going on there).  In the 2-row scenario, you're still unlikely to get a lot of benefit from parallelism here.

Overall: even if you were able to manage to get the NL join to be parallel, it doesn't seem like it would help you very much.



For a more general treatment of why parallelism might be inhibited in portions of a query plan, or the entire thing, see SQL not engaging parallelism for extremely large query.