Lambda application terms MN where M is not a Lambda abstraction term? I believe such terms are syntactically legal in (untyped) lambda calculus (see below), but the motivation for including them is not very clear to this newbie (e.g. because MN has no potential for reducibility). Perhaps I am hung up on the fact that while computation is about reduction, we are permitted to introduce irreducible expressions. I see that MN might reduce in a broader context, e.g. $(\lambda x. PMN)$. Perhaps this is  why it is permitted. I guess this freedom is not necessary (?) but adds some additional expressive power?
For reference, recall that the class of $\lambda$-terms is defined inductively as follows:

*

*Every variable is a $\lambda$-term

*If M and N are $\lambda$-terms, then so is (MN)

*If M is a $\lambda$-term and x is a variable, then $\lambda x.M$ is a $\lambda$-term.

 A: In the untyped $\lambda$-calculus, one can indeed write "meaningless" terms. Such terms include the application of a non-function to an argument and the application of a function to an argument over which the function is not defined.
When attempting to evaluate such terms, you end up getting stuck at a point where you have reached an expression that is not yet in normal form, but can neither be further reduced. (After our discussion in the comments, I have to add that I consider reduction only over well-scoped terms, since  it makes no sense to reduce open terms that have no meaning.)
I don't think historically there was motivation for allowing such terms. On the contrary, after the untyped $\lambda$-calculus, came the simply typed $\lambda$-calculus (STLC) that disallows such meaningless terms, but on the other hand it can be too restrictive. For example, the fixed-point combinator $\lambda f.(\lambda x. f\,(\lambda y. x\,x\,y))\,(\lambda x. f\,(\lambda y. x\,x\,y))$ that allows general recursion in the untyped $\lambda$-calculus, is no longer an acceptable term in a typed $\lambda$-calculus. In order to gain back recursion, you need to add it as a language primitive with new typing and evaluation rules for it (or use other techniques).
Another problem that simple types introduce is more practical rather than theoretical and involves code modularity. When coding, usually you want a single concept to be coded in a single place. This is not always possible in STLC (but is possible in System F, which is a more advanced typed calculus). Take for example the identity function $(\lambda x. x)$. In the untyped setting, you can assign this function to a variable named, say, "id" and then you can use id on any argument. In STLC, on the other hand, you would have to define separate "id" functions for applying them on integers or on booleans. These variations of "id" would only differ in type annotations and nowhere else: $(\lambda x : Int. x)$ and $(\lambda x : Bool. x)$. The "id" example is a very simple one, but things can get pretty messy for a bit more complex functions.
So altogether, I'd say there is no motivation to allow meaningless terms, but by disallowing them, you end up loosing more than what you wanted to get rid of. However, there are ways to gain back the extra losses, but then your language becomes more complex.
