I've seen past discussions on this question, but no definitive answers. We can only guess, as I'm sure Fidelity themselves wants to say as little as possible.
I'm going to assume that Fidelity is storing a T9 string of your password as a kind of default "security question" prompt for phone calls. So Fidelity would be storing your password hash, and alongside it, storing your T9 string hash. If that is the case, I don't think it's necessarily a bad practice.
Given that it's handled by the automated system, and not by a live service agent, let's give them the benefit of the doubt and assume that they are hashing your keypad entry and comparing it against a properly salted+hashed T9 string of your password. This is unlikely to expose your credentials during transmission, since this isn't any worse than entering your password in a form field on the web.
But what about if Fidelity gets breached, and attackers get the hashes of not only your password, but also the T9 hash? Then, attackers could start trying to crack everyone's T9 hashes, and using the T9, figure out the length and likely characters of your password. This would make cracking individual passwords faster.
But if Fidelity had a large scale breach tomorrow, and put out a statement that all of their password hashes were leaked, wouldn't they already be fucked? Like, they would force a password reset on every account anyways. It's not like the fact that attackers can crack passwords faster or slower than normal would change how they should respond to a breach where password hashes are stolen. The cat's already out of the bag at that point.
TL;DR: As long as they are storing this T9 string separately from your actual password hash, it's not likely IMO to make or break the security of your account