Counter-question: why should every type be inhabited by a term? You could not have the Curry-Howard correspondence between typing systems and logic if every type was inhabited.
Concrete answer: I don't have Pierce's book handy, but I think you are talking about the system $\lambda\underline{\omega}$ in Barendregt's $\lambda$-cube, a classification of typing systems along three orthogonal axes. (Please correct me if I'm wrong.)
$\lambda\underline{\omega}$ is the simplest extension of the simply typed $\lambda$-calculus allowing type-level computation. Note that $\lambda\underline{\omega}$ doesn't have parametric polymorphism or
type dependency. One way of thinking about $\lambda\underline{\omega}$ is that type-level computation is carried out by having another $\lambda$-calculus, but this time at the type level.
You can think of type-level computation as being run at 'compile time'.
Why use a typed language to run type-level computation? Why not use the untyped $\lambda$-calculus at the type level? Because the things that could go wrong at the term level with untyped terms (e.g. ill-formed programs like $3 + hello$) could now go wrong at the type level (e.g. $\mathbb{B}\; Pair$). So $\lambda\underline{\omega}$ needs a way of preventing ill-formed type-level computation.
But how? Well, let's use the simply typed $\lambda$-calculus again, but now at the type-level, to carry out, and constrain type-level computation? In order to avoid terminological confusion, we speak of kinds of for this second simply typed $\lambda$-calculus. In summary:
(As an aside, you can iterate this and have kind-level computation in the same way and so on, but that's not done in $\lambda\underline{\omega}$.)
So far, I've said that kinds classify types. That's another way of saying that well-formed programs for type-level computation inhabit kinds. In $\lambda\underline{\omega}$ kinds are given by the grammar
$$
\newcommand{\TY}{\mathsf{Ty}}
\kappa\quad ::= \quad \TY\ \ |\ \ \kappa \rightarrow \kappa
$$
Here $\kappa \rightarrow \kappa'$ is the kind of type-level functions such as
$\lambda t^{\kappa}. \mathbb{N} \rightarrow \kappa$.
But what is $\TY$?
Answer: the base kind. The kind that is inhabited by
all types that can potentially be inhabited by terms, e.g. types like $\mathbb{B}$
or $\mathbb{N} \rightarrow \mathbb{B}$. It is the only kind that is
inhabited by types. This gives a neat classification of type-level programs into
types usable to be inhabited by terms, and type-level programs that are only used as components in the computation of such types.
Operators like $Pair$ are not kinded by $\TY$ and so cannot be
inhabited by terms. Instead $Pair$ has the kind $\TY$ $\rightarrow$
$\TY$ $\rightarrow$ $\TY$, which, by its very shape, cannot be
inhabited by types, it can only be used as a program in a type-level
computation. Now $\mathbb{N}$ (integers) and $\mathbb{B}$ (Booleans)
both are kinded $\TY$, hence the type level program $Pair
\;\mathbb{N} \;\mathbb{B}$ also has kind $\TY$ and can therefore be
inhabited by a program.
