The definition ins wholly analogous to the one of State, except that the state is not updated or returned by the wrapped function.
ask is analogous to get; there is no function corresponding to put, however, as the bind operator does not propagate changes to the environment - thus the name of local, which applies a function to the environment within the reader. (That isn't a problem in most cases, as Reader is tailored exactly for cases in which the State infrequently or never changes.)
Reader looks a bit boring - just a vanilla function wrapped in a constructor.
It, however, is simpler to use than State, which can be worth it if state transitions are inessential to your stateful calculation.
Also, there are a number of very practical situations in which some function argument is being used as a static environment: key-value dictionaries, configuration settings, fixed parameters for a model, strategy-pattern functions, etc. Passing this kind of stuff around as argument to every other function gets annoying quickly. Reeader provides a way to combine functions acting on a shared environment in a single computation, and thus removing boilerplate.
Using a CarModel environment (with a torque curve, gear ratios and whatever else you want) to compute, from an rpm value, stuff such as effective torque and power curves for each gear, predicted speeds at some rpm/gear state, aerodynamic drag, top speed, etc.
The Reader monad as a fancy way of doing function composition. Show that in a way other monads were also like that, except that there were other details obscuring the view.
Rhetorical question (posed as an exercise): How far we are from an actual drag racing simulator? (A: not much - all it is necessary is to switch the computations to the State monad so that changeable state like current speed and time can evolve).