What is the "question" that programming language theory is trying to answer? I've been interested in various topics like Combinatory Logic, Lambda Calculus, Functional Programming for a while and have been studying them. However, unlike the "Theory of Computation" which strives to answer the question of "computability" i.e., things that can/cannot be computed with various constraints, I'm struggling to find the analog for "Theory of Programming"

Wikipedia describes it as:


  Programming language theory (PLT) is a branch of computer science that
  deals with the design, implementation, analysis, characterization, and
  classification of programming languages and their individual features.


This is like saying "everything" which isn't really specific.

The common progression of the topics is usually like so:


  Combinatory Logic > Lambda Calculus > Martin Lof Type Theory > Typed Lambda Calculus > (Something happens here) > Programming languages developed - that have very little connection with CL/$\lambda$


I can see the underlying "math" involved with CL/$\lambda$ and interesting proofs that come out as a result including the Church-Rosser theorem and that's neat. However, I'm struggling to understand the "end goal" of all this undertaking? What's the holy grail of PLT if you will? For now it seems to just be scratching an intellectual itch but I can't really cross the bridge from research/theory to anything practical.

Note: I do get it up until using the $\lambda$-calc for undecidability proofs. But beyond its applicability to "computability" I just don't get it and am having a hard time even understanding the need for research in PLT from this narrow POV. Any existing books, references that can throw light on the "big picture" of PLT?
The overall purpose of PLT is to make industrial software 
engineering (in a general sense) cheaper (also in a general sense), through optimising the most
important tool (programming languages) and associated tooling
ecosystem.

Some reasons why maths is involved:


PLs are highly non-trivial, and it's not clear that  they
do the right thing without proof. The maths gives a simplified model
of real programming languages. This model lets us study real programming languages in a much simplified setting, removing (hopefully) most problems already at the model level. Real programming languages are currently mathematically intractable. In other words: lambda-calculus is the fruit-fly, the E.Coli, the spherical cow of PLT.
PLT lacks suitable empirical methods, which would be nice / better
to have, so maths is done as a substitute.
The maths is beautiful and deep.
The maths gives a simple, tried and tests research methodology, which  is  important for helping one's  PhD students graduate. Typically, some variant of e.g.:
Investigate PL feature XYZ through adding it to lambda-calculus. 
Add simple types for XYZ and prove type-soundness.
Add generics for XYZ and prove type-soundness.
Prove a parametricity theorem for XYZ generics.
Add dependent types for XYZ and prove type-soundness.
Develop a partial type-inference for XYZ dependent types.
Add gradual types for XYZ and prove type-soundness. 
Add contracts for XYZ.
Each of those is a paper.  You can stop if your PhD student or postdoc runs out of time.  Each of the above is interesting and will yield insight about generics, parametricity, type inference etc.  This pipeline is a great way of navigating the difficult waters of all possible programming languages. A second way of learning is implementing languages in a compiler, but that's less tractable for an individual.


Whether PLT is needed is an interesting question. Most working
programmers seem to think it's not. They are wrong: most languages developed by
working programmers without a PLT background    (e.g. Javascript, PHP)
start out terrible, and make all the mistakes that PL theorists
long learned how to avoid. If a PL developed by an amateur hits the
mainstream, PL theorists need a decade or so fixing the obvious flaws
(e.g retrofitting a static typing system, see Typescript). Let me summarise this situation:

 Every successful programming language ends up being ML! Either because 
 it was designed by a PL theorist as ML from the start, or because a 
 decade of painful evolution removes all the obvious flaws, leaving ML. ;-)


Aside:
This state of affairs is entirely   the fault of PLT because because most of them have no industrial programming
experience, so don't really know what the pain points of working
software engineers are. In particular, for sociological reasons, most
PL theorists think that pure functional programming in languages like
Agda is the solution to all problems, which does not stand up to scrutiny.