RSA-KEM: minimal number of random bits
Theoretical concern.
The standard security reduction of RSA-KEM to the RSA problem relies on the ability of the decryption oracle to handle most of the input space.  If you don't feed all the bits into the KDF, or if you treat some inputs equivalently, you may shoot yourself in the foot, like failure to verify lHash in OAEP.

Practical concern.
If you don't generate all of the bits of the element $x \in \mathbb Z/n\mathbb Z$ from which you derive a key $k = H(x)$, even if you spread them out so that the standard real number cube root attack doesn't work on exponent $e = 3$, you may nevertheless be walking headfirst into the Franklin–Reiter related-message attack, which applies even to exponent $e = 65537$ that everyone quietly accepts without the PTSD over $e = 3$ left from the dark ages of cryptography engineering in the '90s.

Performance concern.
It costs at best about 20k cycles on a modern AMD CPU to compute $x^3 \bmod n$ for 2048-bit $n$—the faster half of RSA with the fastest exponent; any other exponent is slower (except perhaps in Rabin territory), and decryption is much slower.  It costs at worst about 1k cycles to generate 2048 bits with Salsa20 using naive C code, and that's about the easiest option, not the cheapest option.

OAEP also needs to generate about $\lg n$ bits of data, but usually with a much more expensive PRNG (‘MGF’), such as SHA-256.  Under what circumstances could the generation of $x$ be a bottleneck, but not the MGF computation of OAEP?