If we're talking about an air gapped device, that's because we cannot trust our other devices. So, let's assume somebody has one of these printers, but all of his computers are compromised with bitcoin-stealing malware.
While he uses the printer to generate addresses, and only gives these addresses to those that should credit him, he should be safe - assuming the malware is not advanced enough to also tamper the messages where the user sends his addresses to others.
But what would this user do when he wants to spend the money he has in these safe addresses? If he loads the private key into any of his computers, he loses the money.
Actually, I kinda had in mind users who are already so distrustful of their computers as to boot from a live CD every time they create new wallets, and even to create transactions if those wallets are intended for more than one use. This device would simply be a more convenient way to do the same thing.
For such a device to be complete, it should be able to generate offline transactions as well. But that would probably require a way to scan QR-codes. Manually inputing addresses is error prone and annoying.
Anyway, this increases the complexity of what you're trying to do...
All true. I would love for the device to generate transactions, too, but like you said, manual input of addresses is problematic and adding a camera or the like increases the complexity beyond what I had in mind. But I'll keep brainstorming. Manual input, annoying as it is, wouldn't add too much complexity if the device already had a keyboard and screen (like casascius's POS terminals). Hmm...casascius, do your POS terms support a barcode scanner? Maybe the printer could output an old fashioned barcode instead of/in addition to a QR code...?
Thanks for the link, I hadn't seen that thread yet. Looks like I've got some more prior art reading to do!

If someone could create a module in C[...]
Are you really gonna make me finally learn C? I've managed to avoid doing so for over 20 years now...

-Mo