The advantage of a transaction with many confirmations as opposed to just a few is that you can be more "certain" that the transaction has been accepted into the network. There is the potential that what your personal client thinks might be a confirmed transaction may be in a block that is accepted by some nodes and rejected by others (aka a fork in the blocks). This happens from time to time and it isn't something to be very worried about, but as more confirmations happen the deeper that transaction is into the block chain making it much less likely that the block it is attached to will be rejected in the future.
Just because a block is rejected doesn't mean the transactions that are in it will vanish, they'll be included in the other for branch anyway.
The only transactions that actually get rejected when a fork branch is discarded are the generation transaction, that's why the standard client considers them valid after more confirmations than regular transactions.
When a block is rejected obviously the "mining" transaction for that block is also rejected (as you suggest here), so there is at least some loss, plus there is entropy in the system where from time to time (as people turn on and off clients) that over time transactions will be dropped.
I know this is semantics and splitting hairs, but there is at least an outside possibility where transactions with no fees or low fees will not get incorporated into any block at all... depending on the rules that most of the miners are using. There is a sort of mean lifetime of a transaction and if it doesn't get incorporated into the chain it may eventually vanish altogether. Transactions of coins less than 0.01 BTC are examples of transactions that will likely not be incorporated in any particular block (if there is no fee attached) as most miners reject those transactions. Some miner might, however, and in that case if the block where such a miner incorporated a transaction of that nature but the block itself was rejected for some reason (including that in the competition for "winning" the block somebody else got their block in first even though both blocks had "successful hashes") those transactions simply bounce around the network as unconfirmed transactions.
It is also possible that peers may choose not to relay all unconfirmed transactions, for whatever selfish reason they choose. I know that the current client is usually agnostic in that regard, but there isn't anything stopping a node from relaying only transaction from any domain ending in *.pk or excluding all transactions from a *.ru domain (to give an example only... I'm not picking on any country in particular!) Other criteria could be developed but once the transaction is incorporated into the chain recognized by the vast majority of the computer power of the network, such games for unconfirmed transactions are over. Rejecting blocks by a particular node when the rest of the network accepts the block will end up being a futile exercise.
