Hi Ati. The default size of 8192 determines part of the overhead for each connection to mongod: each connection can have an overhead of 8192KB for the stack size, using up some RAM.
As the case study discussed, Server Density saw queued queries because of contention for RAM. This RAM contention was caused, in part, by the number of connections to mongod processes (and this number was large, ~1500/mongod). Each connection had an ~10MB RAM overhead because of the stack size ulimit, and with the number of connections they had this used too much RAM. Part of their solution was to reduce the ulimit for the stack size to 1024. This isn't free- when you reduce the ulimit, you will cause problems whenever a connection thread runs into the new, lower ulimit. This was a very specific fix for the very specific situation that Server Density found themselves in. Unless you find yourself suffering from a similar performance bottleneck, have thought about if decreasing the stack size ulimit makes sense, and have tested it for adverse effects, I wouldn't recommend changing the ulimit. Don't prematurely optimize.
-Will