Unlike many traditional database products, PostgreSQL does not assume or even prefer that the majority of the memory on the system be allocated for its use. Most reads and writes from the database are done using standard operating system calls that allow the operating system's cache to work in its usual fashion. In some configurations WAL writes will bypass the OS cache, that's the main exception.
If you're used to a database where most system RAM is given to the database and the OS cache is bypassed using approaches such as synchronous and direct writes, you don't want to set up PostgreSQL the same way. It will be downright counterproductive in some areas. For example, PostgreSQL's stores commit log information in the pg_clog directory. This data is both written to and read from regularly, and it's assumed that the operating system will take care of optimizing that access. If you intentionally bypass PostgreSQL's intentions by using mounting tricks to convert writes to synchronous or direct, you may discover some unexpected performance regressions due to this issue, among others.
So why not just give all the RAM to the OS to manage? The main reason that the PostgreSQL shared buffer cache can do better than the operating system is the way it keeps a usage count of buffers. This allows buffers to get a "popularity" score from 0 to 5, and the higher the score the less likely it is that those buffers will leave the cache. The way this works, whenever the database is looking for something to evict to make more space for data it needs, it decreases that usage count. Every increase in usage count makes that block harder to get rid of. The implementation used is called a clock-sweep algorithm.
Typical operating system caches will only give any buffer one or two chances before that data is evicted, typically with some form of LRU algorithm. If your database has data in it that accumulates a high usage count, it's likely that data is being served better staying in the database's shared RAM than in the operating systems.
There are also some optimizations to the PostgreSQL buffer cache to deal with large queries, such as sequential scans of the entire database and VACUUM, which lets it hold onto important data that's likely to be blown out of the operating system cache as part of doing that job.