Using AES-256 instead of, say, AES-128 is not merely ‘future-proofing’: AES-128 provides a security level far below the standard of 128 bits today. If your application has four billion users, the expected cost of breaking one of them by the best generic brute-force attack is about $2^{96}$ evaluations of AES-128, which can be parallelized. This might not break your toy application, but it is well within the realm of human feasibility. Not so for AES-192 and AES-256: even up to a whopping sixteen quintillion users, the expected cost of the same attack on AES-192 is an unimaginable $2^{128}$ evaluations of AES-192.
So if you want AES—which invites timing side channel attacks on software implementations, unlike, say, ChaCha—then you should pick AES-192 or AES-256 without further thought. This saves you the effort of thinking about whether AES-128 provides adequate security for your application. AES-192 and AES-256 are marginally costlier than AES-128, so if you have an overwhelming performance concern then we can discuss the finer details when you present a budget measured in joules or nanoseconds or cycles per unit of processing in your application, and not until then.
The story is more complicated for RSA, and depends on what you're doing with it:
- If you're using it for signatures, you will presumably have some way to rotate signatures—unlike confidentiality, authentication generally need not last for decades.
- The number of RSA keys is likely to be considerably smaller than the number of AES keys, if for no other reason than that generating an AES key costs a few dozen CPU cycles while generating an RSA key involves a search through complicated primality tests.
- RSA computations are substantially costlier than AES computations at any reasonable key size, so your budget for time might actually be measured in milliseconds rather than nanoseconds, like human response times.
- RSA key sizes are substantially larger than AES key sizes, so your budget for time might actually be measured in kilobytes rather than bytes.
All these considerations might figure into your application: it would not be hypocritical to pick AES-256 and then spend your time worrying about RSA, if RSA-4096 is too costly. Heuristically, we might infer that RSA-2048 is safe for the time being because the current factorization record is RSA-768, and while we're overdue for an RSA-1024 factorization, there's a big gap from there to RSA-2048. But it is also true that a 2048-bit RSA modulus certainly doesn't attain a 128-bit security level either. The best cost estimate I'm aware of gives an area-time cost per key of about $2^{103}$ if we conservatively read $o(1)$ as zero, rather than the cost $2^{112}$ advertised by keylength.com, NIST, etc.
That said: Can I interest you in Ed25519 or X25519, which confidently provide a 128-bit security level—meaning the best attack has expected cost $2^{128}$ curve additions no matter how many users there are—with 32-byte keys and 64-byte signatures, and at much lower cost to generating a key or making a signature or decrypting a message than RSA will ever attain? Then, unless your bottleneck is verifying signatures or encrypting messages, you don't have to spend time thinking about whether RSA-2048 is secure enough as you use it in your application. (See also this earlier answer to a similar question about AES-128 and X25519.)
