I also don't like the explanation of constants in the article, but there are reasons for them.
You can certainly consider constants also in untyped lambda-calculus, and the behavior of constants is not generally interesting — as long as you allow them to be there.
However, most constants are typically redundant in untyped lambda-calculus, because any datatype can be Church-encoded. A typed variant of Church-encoding (called Böhm-Berarducci encoding, often also called Church encoding) is also available in polymorphic lambda-calculus (System F) and calculi containing it (TAPL*, Sec. 24.3).
However, Church encoding does not really work in STLC: if you try to write 2 as
λ zero succ . succ (succ zero), you'll find you need to fix in advance what type τ to use for the type annotations
λ zero : τ. succ : τ → τ . succ (succ zero). Once you fix τ (say to Bool, assuming you have that type), you can only compute booleans with it, not anything else (in particular, not even numbers).
There's also another problem: unlike in System F, pure STLC the set of types is empty, as one can see by examining the definition of types (TAPL, Figure 9-1):
T ::= T → T
Since there is no base case, one can construct no finite type.
This is a different problem, and to solve it it is enough to add a set of uninterpreted base types. However, to make the calculus useful, you need to allow at least for arbitrary uninterpreted constants.
Theoretically speaking, this is not a small problem in theory — every interesting bit of proofs about STLC can be done without base types, but all the statements are also vacuously true since no typed terms exist (because there is no type to fill in the type annotations).
*TAPL is the book Types and Programming Languages by Benjamin Pierce, a standard reference nowadays in its field.