What is the "question" that programming language theory is trying to answer?
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.