Let's say you have your wallet.dat encrypted on the internet facing server, but need to unlock it all the time to refill the pool when generating new addresses (because the service does that for every visitor) and when doing transactions.
So, effectively it's being unlocked like every 10-20 seconds or so when the site gets traffic.
In that case is there any point to encrypt it at all?
An encrypted wallet.dat remains encrypted on disk even when unlocked, it's only unlocked in RAM. Depending on your application design, this could improve security. For example if you have a 2-tier app plus bitcoind, where only the backend tier has access to bitcoind, then a vulnerability in the frontend tier which permited read access to the wallet.dat file would not on its own compromise the wallet.
How does encryption affects performance on big wallets?
Unlocking a wallet takes about 0.1 seconds of CPU time, during which time most other wallet operations are suspended. The number of keys in the wallet does not affect unlock performance, a key is only unlocked when required (for as long as the wallet remains in an unlocked state). If performance is a concern, you should consider specifying a longer timeout when unlocking the wallet, and then anytime you need to perform an operation which requires an unlocked wallet, you should start off by assuming it is already unlocked, and handle errors where your assumption was wrong by unlocking the wallet and retrying the operation.
Newer versions (starting from 9 maybe?) don't require unlocking anymore when requesting new addresses.
I assume that unlocking becomes required once the key pool runs dry, correct?
Incidentally, secure application design is really hard... if you're not an expert (not that I claim to be one), you might be getting yourself into trouble with storing a wallet on an Internet-facing server...
