There's no definitive article because the answer is always "it depends". The more plug-ins you use, the more virtual instruments you use---basically, the more loaded your CPU is---the more buffering is needed. Using a larger total buffer size reduces the number of callbacks into the application, allowing it to handle harder workloads without losing data, but it's really more complex than that.
The recording buffer
This goes by many names---sample buffer, hardware I/O buffer, etc. It's all the same. This refers to the size of the chunk of data that the driver sends to the audio application each time it sends data. With smaller buffer sizes, the kernel is interrupting the audio app more frequently, and there is some overhead associated with that. Thus, larger buffer sizes can reduce CPU overhead, but do so at a cost---higher latency.
It is important to note that generally speaking, the buffer size is meaningless as far as the hardware is concerned; it is strictly a contract between the driver and the application. It is also not the only source of latency; the application is not talking directly to the hardware. In addition to the time it takes to fill a buffer chunk and issue the callback to the application, you also have the read-behind latency in the driver itself plus potentially other ring buffer latencies in the software stack. This all adds up. How much depends in large part on the OS and driver model.
The buffer size is measured in terms of samples. Fortunately, whether you're recording at 24-bit or 16-bit, the audio app is probably taking 32-bit floating point samples anyway, so this really doesn't matter much; it could just as easily be bytes for all it matters; multiply by 4.
The buffer size is basically independent of sample rate, with the caveat that every time the application has to take in data from the driver, it must stop what it is doing and run the main audio I/O thread. The process of switching gears takes time away from processing, and thus, the more frequent this happens, the bigger the CPU hit. At faster sample rates, the CPU will be interrupted more often (since the buffer size is in terms of samples and not in terms of milliseconds as it rightfully should be). As a result, you may have to increase your buffer size at higher sample rates if your CPU can't keep up.
A good general rule is to record at the lowest sample rate, then back off until you get a recording without glitches, then back off one more time to be safe.
That's truly the only advice that is generalizable....
Other buffers
Many audio apps also have buffers for disk I/O. This was far more important ten years ago when OSes had no built-in disk caching or read-ahead, but even today, it can be useful. A good general rule is to make sure your disk cache fits in main memory without causing unnecessary paging. A portion of an in-application cache that gets paged out to disk is no better than re-reading the same data from the file.
Also remember, though, that larger buffers tend to result in long delays when you hit "Play" while the application reads audio files from disk and caches them in memory. Although larger disk caches can be helpful in preventing glitches when you're right up against the limit of your CPU or HD performance, you're usually better off upgrading your hardware.
If bumping the disk cache way up makes a huge difference in reliability, this usually indicates that your audio app was written incorrectly and isn't requesting data form the disk early enough. This is common with older audio apps and external hard drives. Caching may help work around the problem, but odds are the problem will still find a way to bite you in the backside. Upgrade your audio app in that case.
