(I proposed this in #79 as rational-expt but misdesigned and misexplained it, so it was quite properly shot down).
The expt procedure is part of the inexact module, as its result is not necessarily rational. This means that Schemes which do not provide inexact numbers will not provide expt either.
However, expt can safely return an exact result if its first argument is an exact number and its second argument an exact integer. Providing a separate exact-expt procedure in the base module allows this restricted but very useful functionality in the absence of inexact number support. Exact-expt would be analogous to exact-integer-sqrt, which is likewise in the base while sqrt is in the inexact module. Implementations which do provide inexact numbers (the vast majority at present) can simply equate exact-expt with expt.
Alternatively, we could move expt to the base module. In that case, implementations without inexact numbers must report an implementation restriction when the second argument is not an integer.
expt is already in the base library and no one has suggested otherwise.
Actually, the second argument doesn't have to be an integer: the result of (exact-expt (/ p q) (/ j k)), where p q j k are all integers, is exact iff the kth root of both p and q is an integer. So the domain of exact-expt is any pair of exact rational numbers (but in some cases an exact result cannot be returned, in which case the behavior is unspecified).