It slowly but naturally introduces gameplay elements. You're started out with the simple task of keeping the fire going, then new options sprout naturally and at a good pace.
It's also incredibly atmospheric despite or because of its minimalism: there are no graphics, and not even colors. The writing has an odd, clipped tone to it, and provides just enough information for you to fill in the pictures vividly.
Of course, the other reason I really like it is that it's both a building-centered strategy game and an exploration game - probably my two favorite genres. I'm writing an exploration game myself, after all. The resource management mechanics that underlie both the strategy and exploration are suitably straightforward and uncompromising - here's a game that makes you track your food and water independently, and makes you hesitate about each bullet you use. This might sound tedious, but the result is a feeling of risk and danger and lots of hard choices.
The interesting limitation that this game observes is that entities don't have properties: all furs are the same, all rifles are the same, all bullets are the same. You could express the entire game state as a list of values: you have five bullets, one rifle, 253 furs, etc. Even the map can be represented like that, since it's of a fixed size: each tile contains no more information than the letter you see on the screen.
To me, this is a very interesting limitation: it keeps the UI simple (no need for complex displays when everything is just a number), and it makes it harder to plaster over design problems by adding complexity. It's a limitation I definitely want to try out in a prototype soon. (As a side effect, this also makes saving/loading games trivial, and debugging rather easier.)
A Dark Room, along with Twine, also really shows that you can make great games in HTML and JS, without even having to resort to canvas - yet another choice or limitation I want to try out.
Finally, note that ADR is open source. It's on GitHub, and you can fork it to your heart's content. Michael Townsend, the developer, is very responsive and enthusiastic about accepting pull requests. I should know, I've been making lots of them.