SQL Server might split each operation (table scan, index seek, aggregation and so on) up to MAXDOP threads. The threads are created and destroyed on use basis, and the total number of threads used in a query might well exceed MAXDOP, since each parallel operation might have its own thread. As per the docs:
The max degree of parallelism limit is set per task. It is not a per
request or per query limit. This means that during a parallel query
execution, a single request can spawn multiple tasks up to the MAXDOP
limit, and each task will use one worker and one scheduler.
The query optimizer doesn't need to use parallelism. The optimizer looks for good enough a plan, and for trivial queries it is often decided that a serial plan is more efficient than building and running a parallel plan. Parallelism has its drawbacks, not all operations parallelize nicely, and there is extra book-keeping involved on thread synchronization.
See also Paul White's nice overview about parallelism in SQL Server.
Blocking is caused by a session that holds a lock to a resource. That doesn't depend on parallelism - unless there would be a query that greatly benefits from parallel plan, but MAXDOP is set to one. In such case, leveraging parallelism would just release the lock faster, leading to less blocking.