We don't integrate some sort of CRC because of saving a tiny bit of memory in the core code and because sort-of-CRC could be done in a/the client, right?
No, because in the core and when sending across the network the transactions are already signed with the sender public key. Any corruption in the transaction content would automatically invalidate the signature.
So what? Buffer, from which recipient's address is taken could be corrupted, user could made a typo.
Maybe somebody don't understand. One can make a very easy experiment: send small amount of Nxt to a known address whith one digit randomly changed. Such transactions are accepted and gladly confirmed by the network. That wouldn't happen with Bitcoin or any of it's copycats.
There is only one proper solution for that. Extend Nxt address with (preferably) 4 bytes of checksum. I'm not a Java developer, I don't know details (and I haven't read the code), but I stronly beleive there are readily available classes for big ints, use them instead of primitive data type which is apparently being used for addresses now. Or write your own class. You need a method to take significative part of a new address, method to convert old address to the new form. From block XXXXX use new addresses, make proper conversions when you deal with old blocks. That should be easy.