I see three kinds of weaknesses here. The need for padding is not an implementation weakness but an algorithmic weakness. RSA is not an encryption algorithm nor a signature algorithm; RSA-OAEP and RSA-PSS are. It's easy to avoid algorithmic weaknesses: stick to approved algorithms, i.e. OAEP and PSS from PKCS#1 v2. If required for interoperability, you can safely use the PKCS#1 v1.5 schemes in many scenarios, but carefully check the known weaknesses in these schemes against the specifics of your protocol first (what gets RSA'ed, how many messages with the same key, etc.).
A potential source of weaknesses is key generation — things like “use a proper random generator”, “don't pick a small $d$”, etc. This is intermediate between implementation and algorithm: it's up to the key generation algorithm, but two different implementations can use different algorithms without breaking interoperability, so there is considerable variation there.
Unfortunately, there isn't a universally-followed standard RSA key generation algorithm like there is for DSA. Reid cited the Handbook of Applied Cryptography which provides a good checklist of do's and don't's (§8.2.2–8.2.3). NIST specifies RSA key generation in FIPS 186-3 §B.3 (they're for integer factorization cryptography (IFC), which in practice means RSA). NIST also publishes generic recommendations for key generation in SP 800-133.
I also recommend reading Cryptography Engineering by Bruce Schneier et al.
A different source of weaknesses comes from the implementation itself. An adversary may be able to observe secret data and extract all or part of the key or message from that. Such attacks are generically known as side channel attacks. Timing is a common one: if the adversary knows how much time an RSA operation took, he might know how many bits were 0 or 1 in the key or in some intermediate result. If the adversary can observe how CPU load, cache use, power consumption or radio emissions vary over time, he may be able to “read” the key from such side channels.
Hardening against side channels generally involves a compromise with performance. For example, blinding involves doing extra operations to encode and decode the data before and after the RSA operation, so that a side channel would only reveal information about values that incorporate a random element and from which the actual data cannot be retrieved.
Closely related to side channel attacks are fault attacks, where the adversary is able not just to observe but even to partially affect the execution of the cryptographic implementation. Fault attacks are mostly relevant to devices that must resist physical attacks such as smart cards. Hardening against fault attacks again involves a compromise with performance, for example performing the same mathematical operation in two different manners and checking that the results match.