The argument for using SSL is to prevent some malicious user who has gone through the pains of snooping your traffic being able to read your traffic. So while it may make se
SSL provides authentication and encryption.
It is somewhat difficult to MITM an unencrypted connection, but not so hard on the unencrypted wireless network you gave as an example. Any network that allows you to ARP spoof (many switched wired networks) allows you to MITM as well. But you're forgetting about every router along the way. Remember a few months back when a (hopefully) poorly configured router in China routed a significant, though small in relative terms, portion of Internet traffic? They could've seen your plaintext. So can other customers on a cable network, and so on.
But SSL also provides authentication. If I get the private key to a valid SSL cert from you, I'm damn confident that you are who you say you are - doubly so if it's a competent CA.
But the bigger concern is - you don't quite seem to understand SSL, so I'd advise you against making a decision one way or the other by yourself - at least until you read more. SSL does not require you to generate a new key every request, and in fact would not work if it did. Furthermore, any reasonably-recent computer can handle thousands of SSL requests simultaneously - the algorithms are very fast. Furthermore you can use encryption accelerators that offload the work to a dedicated piece of hardware.
If you think you might need to use SSL to secure some data, and often if you don't, there are almost no reasons to avoid it. Yes there is some expenditure involved but any data of consequence is worth the $300/yr.
EDIT I read your comment - this is a client app? The solution in your case is probably to use self-signed keys, and you can distribute the public key with the app. This allows you to encrypt and verify that you're talking to who you should be.