This is the problem: there is a game-stat, and that game-stat is displayed to the player on the HUD. OO speaking, how should the graphic element and value element relate to each other?
I usually make a "normal" game entity have all its variables. Then it knows what to do for a update() and a draw(). For a HUD element, even though it shares the same methods, I'm reluctant to do that.
For instance score. Let's say the score is a multiple of 100, but the representation when the score changes rapidly goes over the decimals and units. (You probably know this effect.)
If there is a separate ScoreHUD object, it has to query the actual score for each draw, AND remember what the last value was.^[1]
If there is a Score object that knows how to draw itself, all changes have to go through that object, AND it needs to be queried any time some other part of the game needs to know the score.^[2](Temporary power-ups might be a better example for this.)
Both sound like they have set-backs. I guess, you could go for event-listeners or (some other kind of) message passing (?). But maybe that's giving up speed for superficial "cleanliness of code". Especially if this would be the only part that benefits from such changes^[3]
Any thoughts, rants, reading, or other on this?

I think this is the essential part. Thanks for mentioning that. When I start thinking, I don't stop thinking. I then sort of over-engineer out of insecurity.
Another rule to add to my personal book: if you can't think of a better solution, don't try to make a better solution.

To me, the natural design would be as follows:

The actual value of the stat is owned by the primary object that it relates to (e.g. the player object). Anything else that wishes to use this stat interfaces to the object that owns it.

Lets suppose you wanted to re-skin your game: if you have a clear interface to the underlying stats, it becomes easy to write a whole new HUD from scratch that uses the same interface. I'm also in favour of totally decoupling the core game logic from pure "eye candy". A good example being what you just mentioned: the score. The actual value of your score should sit in the core game logic, but eye candy (such as spinning up the score when it changes) should exist in the "front-end" logic.

I think that's pretty much what you're doing in 1), and think it's a far better OO design than the other options.

We're talking about a few bytes/referenced here, so you shouldn't even be thinking about speed.

Cool, cool, cool.

That's what I was talking about. And of-course: once you have an almighty design pattern you have to subjugate all your hard-working code to it. That might actually impact how fast things go.