If there's a mechanism for specifying case on the phone, there can be a mechanism for specifying Q and Z unambiguously. I certainly have used VM systems that explicitly told me to "use 7 to represent Q and 9 to represent Z."
A contractual requirement is one possibility that could explain it, but my suspicion is rather that some legacy code in the system uses Q and Z as special escape characters or delimiters (because of their absence on the phone dial), and it's not worth the cost to try to fix the ancient code (or do all the testing necessary to be confident of deploying a workaround).
As for your voicemail system, that merely gets around the issue of competing standards by enforcing its own. And the mapping has to be repeated to every user for every use of the system. I'd actually consider it an argument in favor of the keypad theory.
Escape codes (or testing codes) is another possible explanation. And legacy code cost is indeed often a consideration.
this is incompetent developers in a dysfunctional environment. there is no good light anyone can throw at it. and no, having the system live since the 50s is not a good excuse. it is certainly not the same system, for obvious reason.
all my really old nokias and ericsson and motorolas (that did have Q and Z :) did not made uppercase... pressing one key over and over would cycle the lower case chars only.
Hence, the remote end must assume the "2" to represent either an "A", "B", or "C". What I'm saying is that it's reasonable to further assume that, if the user pressed "2", they may have pressed it to indicate one of the three corresponding lowercase characters. Humans generally ignore case.
What's not reasonable is to assume that a human, faced with a DTMF pad without a Q or a Z, would press anything. Sure, you could interpret all digits as a possible "Q" or "Z", but it's equally likely that a human in such a situation would leave the character out, or give up and call tech support. It's simpler to just disallow these characters.
But you're making the mistake of assuming they're hashing passwords at all ;)
That, I think, is the correct inference.
If the system shows a misunderstanding of security or makes it clear that shortcuts were taken, then what is to make you think the same didn't occur on a deeper and more important level (databases, security, etc).
It's as simple as:
1) On password change/account create, run through a small algorithm that turns the password into a series of digits that represent the password as if it were entered on a phone.
2) Hash both password and "digitized" password into 2 separate fields in your store.
3) Now support phone inputs for passwords.
If JetBlue has a similar logic system via the phone, I can see why Q and Z or prohibited to allow this existing authentication system to work.
What I haven't seen is a statement as to why this would have been a problem. The reason is that Q and Z were mapped inconsistently across various phone keypads. The present convention of PQRS on 7 and WXYZ on 9 wasn't settled on until fairly late in the game, and as noted, the airline reservation system, SABRE, is one of the oldest widely-used public-facing computer systems still in existence, dating to the 1950s.
https://en.wikipedia.org/wiki/Sabre_(computer_system)
The 7/9 standard, by the way comes from the international standard ITU E 1.161, also known as ANSI T1.703-1995/1999 and ISO/IEC 9995-8:1994).
http://www.dialabc.com/words/history.html
Other keypads may not assign Q or Z at all, or assign it to various other numbers, 1 for Australian Classic, 0 for UK Classic and Mobile 1.
http://www.dialabc.com/motion/keypads.html
Similarly, special characters can be entered via numerous mechanisms on phone keyboards.
My suspicion is that there's a contractual requirement somewhere to retain compatibility with an existing infrastructure somewhere.