And what would be the omitted part of programming language theory?
Looking at mpweiher's profile it looks like he might be interested in things like metaprogramming and object protocols - again they're seen as either part of the software engineering or systems disciplines rather than PLT.
Metaprogramming also has a rich history in traditional PL venues like POPL and ICFP, such as the Scheme/Racket work on macros, Template Haskell and friends, staged computation work a-la MacroML.
I say that I'm a systems person to signify that I want to talk about ASTs, IRs and compiler output rather than core language models and formal semantics.
But you could argue about definitions all day.
The relevant observation is that the reason this list focuses on formalisms like type theory and models we can reason about formally like FP is that this is what we mean by PLT.
First, I don't have specific things that were left out (well, maybe a few), it was more a sense of there is so much more, especially that I would want to know and feel I should know when creating a computer language. The important bits.
First and foremost, programming languages are for people and for building systems. Except for CTM, that seems to be almost completely missing (and I had initially missed that it was actually on the list, so my bad).
So anyway, if you want to have theory of programming languages, you have to have something about how people think and work and how that affects programming language design. As an example, I found John Pane's HANDS system very illuminating, or maybe the "Smalltalk: Bits of History, Words of Advice", which talks about iterating on language usability, or Henrik Gedenryd's thesis "How Designers Work". Not saying these are it, but just the flavour I'd be looking for.
On the systems front, I think I'd want to see how problems building systems lead to features in programming languages, what the tradeoffs are etc. Again, without this, what's the point of a theory of programming language? And I do hope features in programming languages are trying to address actual problems building systems. Otherwise, it would be like having theories of engineering without talking about real world objects that we are trying to build such as airplanes, bridges or buildings.
As a tiny and obvious example, what are the tradeoffs between more compile-time checking with longer compile times and more inscrutable errors and a more dynamic approach with much faster cycle times but less checking? And yes, there are tradeoffs.
When you look at Hennessy/Patterson for Computer Architecture, you see (well understood?) tradeoffs that matter in terms of application. Yes, more registers are good, but then you have encode them in the ISA, and your path lengths increase and you need to save/restore more on a context switch, etc.
One thing that should also definitely be on there is HOPL. Histories of people actually designing programming languages, trying to solve specific problems and then figuring out what worked, what didn't and why. Without some sort of reflection like this (=evidence), again, what's the point of even beginning to talk about a "theory" of programming language? Unless it's a definition of the word "theory" that I am not aware of.