Virtualized SQL Server hits 100% CPU and 0 Active Memory
Check out this interesting post from David Klee: VM Memory Counters Lie for SQL Server VMs

In particular, this quote is very relevant to your situation:


  SQL Server uses memory as a working set I/O buffer, and memory blocks in the SQL Server buffer pool are most commonly used as a read cache. Memory blocks that are repeatedly read only show up in the active counters if that block has been read from or written to in the last sample interval, which is usually 20 seconds. Therefore, SQL Servers that have an appropriate (or too high, but that’s a different story) amount of memory assigned to the VM will have most of the commonly accessed data in memory, but those blocks are rarely accessed in their entirety over that short of a sample window. The VM active memory counters will show a very low active value, but this SQL Server could actually be very busy.


This explains your first issue (related to "active" memory).  In essence, the metric you were looking at isn't reliable, so it doesn't tell us much of substance about the situation.



The other question, related to unresponsiveness, is harder to pin down without seeing wait stats from the time of the outage, or specifics of the recompiled execution plans.

If I were going to speculate, a plausible theory might be that:


queries now running at MAXDOP 2 (instead of 4) take significantly longer to complete
queries are arriving at the server at the same rate as before
so now there are more queries running at once (since they take longer to complete)
the server starts to experience thread starvation (threadpool waits) because there are so many concurrent queries running
if the queries require memory grants, they could also start queuing up for memory (resource_semaphore waits)


All of these things would combine to make your server seem unresponsive.  It might also cause the "active memory" in the VM to drop, since memory pages might be accessed less (due to everything waiting on CPU resources).