Although both @MHM Cisco World and @David Ruess are correct about possible additional delay between router neighbors with some topologies, I suspect Cisco's settings might have more to due with the "complexity" of "hello" peering between routers on certain topologies and/or expectations of how long a network should wait to detect a lost router neighbor.
I.e. what kind of networks needs something like Cisco's default OSPF dead timers of 40 or (especially) 120 seconds? (In the past I've worked with global networks, using OSPF, running across "slow" [e.g. 64 Kbps] links. Even from one side of the world to the other, one direction latency generally didn't exceed a quarter of a second.)
A broadcast medium is likely some form of LAN and p2p will often detect loss of neighbor with a concurrent down interface on both ends of the p2p link. I.e. with a LAN, we might not have multiple peer detection of a lost neighbor from hardware, but can use broadcasts (or multicast) to "quickly" determine status of multiple routers on a shared segment, and as noted, with p2p likely have concurrent down interface detection.
With non-broadcast medium and/or multi-point, complexity of relaying peer status, between neighbors, is more involved.
If you read, for example, OSPFv2's RFC, its hello processing makes distinctions between broadcast, NBMA and multipoint (OSPF RFC hello protocol).
Likely, Cisco set its time defaults to be especially conservative, and to insure they didn't accidentally/incorrectly take down a working connection mistakenly believing it failed. (In an [earlier?] networking world where there were not many, if any, redundant paths, incorrectly taking down a live connection would be worse then "detecting" a real line drop 40 to 120 seconds after it already happened.)
