> when encrypting a session key which is used to encrypt bulk data using a block cipher for example, is padding with OAEP really needed ?

No if the session key is nearly as wide as the RSA modulus, or is padded with random bits up to that size (save for one bit or few high order bits). Absent other issues, we are safe if the actual session key keeps bits from the result of RSA decryption among those that have been chosen randomly, or is obtained by another key derivation step. That's the principle in [RSA-KEM][1].

But yes, [RSAES-OAEP][2] is useful if the session key is directly the payload, and is much smaller than the RSA modulus (which is typical for a session key). OAEP gives a security reduction to the RSA problem, when direct encryption of a short key with textbook RSA (as $C=K^e\bmod N$ ) is known to be insecure in at least the following two cases.

- If the public exponent $e$ is small (less than about $\displaystyle\frac{\log N}{\log K}$ bits), then decryption reduces to computing the non-modular $e^\text{th}$ root of $C$, yielding $K$. This [question][3] asks for a bound for $\log K$ allowing attack, which it is slightly larger than $\displaystyle\frac{\log N}e$.
- If the key $K$ is significantly less that twice as wide as the desired security level, then there's a meet-in-the-middle attack working for the sizable fraction of $K$ that (partially) factor as $K=K_1\cdot K_2$ with $K_1<K_2$ and $K_2$ small enough to be enumerated, requiring $O(K_2)$ time and $O(K_1)$ memory.<br>
That would be a plausible attack for 128-bit $K$ and 4096-bit RSA with $e=2^{16}+1$.

___
> What benefits does OAEP provide compared to simple padding with random bits up to size $n-1$ where $n$ is the size of (the) RSA (public modulus) ?

None that I see beyond

- availability of some secure implementations,
- recognition (including explicit by some security recommendation),
- detection of _accidental_ cryptogram corruption or using unmatched public/private keys.

Beware that implementation of decryption using "simple padding with random bits" is far from foolproof; nothing manipulating secret or private key is. In particular, testing the high-order constant bit(s) leads to disaster by padding oracle attack. Fault attacks may apply (e.g. forcing the session key to be zero with targeted and timed laser pulses). Side channels may be problematic.


  [1]: https://tools.ietf.org/html/rfc5990
  [2]: https://www.emc.com/collateral/white-papers/h11300-pkcs-1v2-2-rsa-cryptography-standard-wp.pdf#page=16
  [3]: https://crypto.stackexchange.com/q/8017/555