Because when you drop that reference, the memory won't be reclaimed, and destructors won't run.

References in Rust aren't like references in GC languages. They don't control object's lifetime.

It's usually considered a leak if we can't release it.

Arguably you can release the thing you leaked with Box::leak(). Just tell Box you want a new box that's just a thin wrapper for your mutable reference (this is unsafe), then drop the box. But generally the purpose of Box::leak() is to never release the thing inside the box.

So, yes, you could argue semantically about whether this is "really" a leak but in practice that's why it's named Box::leak()

My definition of leak would generally be what Valgrind would call a leak. Wouldn't Valgrind not call this a leak given that there would still be a reference remaining at program exit?

If my understanding is correct, the reference could get dropped at the end of the scope while the pointed at memory location will remain in memory - so Valgrind would leak it, but I haven’t tested it.