That's really a design question best directed to the ggroup, but FWIW, I did investigate peek / peek! a while ago and providing peek! seems to be a simple matter of creating a new clojure.lang.ITransientStack interface to parallel clojure.lang.IPersistentStack and having transient vectors implement it.
My guess is that if such an interface is not already available (and used by transients), it's probably a matter of priorities. A single-threaded fast stack implementation is already available in Clojure in the form of java.util.Stack, so we're not missing out on that many features here; syntactic convenience and smooth conversion to persistent vectors will probably come as headway is made on Clojure-in-Clojure.
(Where the return on the effort invested is high, improvements to the Java side of Clojure make sense even if the ultimate goal is eventually to drop the relevant part of the Java codebase and replace it with an implementation in Clojure. Where expected returns are lower, it might make more sense to wait for protocols to be used more pervasively etc. The currently available set of functions for handling transients suffices for Clojure's own needs and I'm not sure if there's ever been call for peek! on the ggroup -- as for #clojure, I remember one relevant conversation -- so the return is probably judged low... You could start a grassroots movements to change this, though. :-))
