Pitfalls of SSD encryption
Keep in mind that modern SSDs already encrypt your data at the firmware level, so that a reformat operation can be done simply by discarding the internal key, rather than wiping every sector. This doesn't mean your data is automagically encrypted at all times - the crypto is only used to fix the NAND-wear issue. However, it does mean that a proper firmware-level format operation renders the data on the disk entirely destroyed for all intents and purposes. If you're throwing away an SSD, I highly recommend using this option. Most major OSes recognise and support the appropriate firmware command, but use of it may differ - check the appropriate documentation.
As far as the wear-leveling spare sectors go, in practice you should be safe regardless of whether or not the stored data was encrypted. Due to the internal encryption, orphaned data blocks in wear-leveling areas shouldn't be recoverable, since the IVs and sibling blocks are destroyed / missing. However, this isn't to say that you might not be unlucky - it may well be that a few blocks of file data end up being kept, leading to a case where a small amount of plaintext is recoverable. It's difficult to say.
Ignoring the internal crypto for a moment, another interesting attack is related to old remnant blocks of ciphertext. If you encrypt a piece of data with a particular key and IV, then encrypt a new piece of data with the same key and IV, it may be possible to attack that data using differential cryptanalysis or other attacks. It also demonstrates active modification of certain areas of data, which may or may not be problematic for you depending on your threat scenario.
On a Flash block, two operations are possible: convert one bit from 0 to 1, or reset the whole block to 0 (the roles of 0 and 1 can be swapped, of course). Each block sustains only a limited number of resets before failing, hence the "wear-leveling" which tries to spread the "reset" operations. Also, error-correcting codes are used to survive a few erroneous bits.
One possible wear-leveling algorithm (or part of a wider algorithm) is to inspect the rate of bit errors in every block when read; when the rate becomes too high (too close to the upper limit of what the error-correcting code can manage), the block is declared "failed" and the next reset operation on that block will instead be a "remap": another block, from the spare area, will be used thereafter. The consequence is that the data in the "failed" block remains there; it cannot be accessed logically (the SSD controller shows the remapped block, not this one) but it could be read by extracting the Flash chip and accessing it directly.
This means that OS-level strategies for wiping cannot be 100% effective.
Many (but not all) modern SSD implements a "secure erasing" feature, in which all data is encrypting with a random key, and when the machine asks for a secure erase, that key is changed. This is equivalent to destroying the data in all blocks, including the data in the now inaccessible blocks, so it is a very effective whole-disk wipe. Mileage may vary on how such a wipe can be triggered, though (by nature, formatting a partition does not trigger a whole-disk wipe, and altering the partition table does not usually do it either). Moreover, security of this process depends on the quality of the encryption used by the disk, which is not necessarily that great, and in any case very rarely documented (most vendors just say "AES" without any other precision). With OS-level encryption, you can have more control on which happens.
If every single data write which has ever occurred on a disk was using appropriate encryption (with a key which is not on the disk itself, of course), then yes, you can discard the disk without thinking anymore about it. The SSD "secure erase" feature MAY embody this concept, assuming that it does not botch the encryption part (but you can rarely make sure about that).