Let's say you want to be extra careful and hash the token in case of a database leak (tokens should expire anyway, but maybe some are still valid shortly after a leak). You also don't want to have any useful information in the token since emails aren't difficult to intercept, in fact, you don't even want to have an incrementing reset token id because someone could see how many tokens have been issued (what they would do with that I don't know, but maybe you're a bit paranoid).
So to have some way to tie it to a user while still hashing it, you decide to take a 256 bit value generated by a CSPRNG, split it in half, use the first 128 bits as an identifier, and the 2nd 128 bits as the token. Both halves are included in the reset token url, the database stores the first half in plaintext, and hashes the second half before storing.
So you've got a 256 bit value now, how do you encode it in the url? If you want to only use letters and digits, you'll need
ln(2^256) / ln(36) ≈ 49.5, 50 characters. So there you go.
I'm not saying everyone using a long reset token is doing it this way, but this is a reasonable thing to do that would require a longer token.
Does this mean a 15 character token is bad?
Not really. It's only got about 77.5 bits of entropy (assuming it's generated by a CSPRNG, which it needs to be), which is a bit low, but if you're not worried about an offline attack (hopefully your reset tokens are short lived), that's perfectly reasonable. It just means there's also a reasonable way to come up with a 50 character reset token. And really, what do 35 extra characters in a url hurt?