Yes wrt first query....actually, that proc is likely not too bad - it is ~1MB of proc cache per plan - I have seen a single plan for a single statement take 100KB. Sometimes it isn't the length of the procs in statements, it is the complexity of the queries. You can't always do anything about it - but sometimes using more simple queries vs. a single complex query not only works better (and is more maintainable) but uses less proc cache to hold the plan.
You are also mostly correct on DBID+ProcedureID+PlanID being unique (ObjectName is not necessarily unique....remember there is proc grouping as well as same proc name in different db's). As far as 0 execution counts, I know for cached statements, it typically is due to a statement that aborted. Not likely for a proc...what is more likely is recompiles - e.g. exec with recompile or other normal recompiles. For example, a proc is first compiled and gets a PlanID....then during execution, it hits a #temp table or @var and uses deferred compilation - which might generate a new plan - not sure if the original cached plan would have ExecutionCount of 0.....
....as far as compiled dates, that is strange. I know sometimes we write stuff back to sysprocedures....but not sure if what you are seeing is a result of that
But....even with that, your proc cache is 5GB......so how did 150 concurrent execs of another proc blow out another 14GB - especially when there are procs with high concurrency. One thing I can think of is what I call the tempdb log segment symptom ....e.g. when tempdb fills, we always get a complaint about the log segment, but we all know that in reality, it was the data segment - and likely a huge cartesian product or something filling the data segment that gave the log nowhere to grow when it had to log a simple allocation. If you are having a lot of recompilation, one consideration is that index histograms are not shared - e.g. if 50 people are optimizing the same table, then if truly concurrent (50+ engines), at some point we would have 50+ copies of the histogram steps. If one of the tables had a lot of steps (e.g. 2000+).....that might take up most of the remaining proc cache - and then it hits the create index and has nowhere to go - the proverbial straw breaking the camels back. The HWM entries on monProcedureCacheModuleUsage might help spot this - especially if rebooting every week. On a similar note, you could probably run the proc 10x and then check monCachedProcedures and see how big the plan is (and how many if recompiling).....