All things equal you're always better off ruthlessly killing complexity. Cook (I know you're not rebutting him) is focused on the problem of unavoidably complex systems. A big server running a single instance of Postgres is great, and you should absolutely use that architecture if you can. But real-world constraints can break the architecture: need it running in multiple locations, with a single global view, with strictly bounded propagation times (for instance: because you're running a routing protocol): it's still just a database problem, but now it's a much more complex one.
And then, naturally, you can get complexity just by building stuff on top of that big database server, and other things that depend on those things.
But then if you keep the components simple - Postgres is a well-trodden path, for example, then you still manage to lop off a lot of complexity. And then of course you can keep the composition simple too - maybe you just need three thumping great Debian boxes running Postgres in three locations, maybe you just need some IPSec tunnels (complex to set up but again a well-trodden path) between them instead of what the latest SDN hawtness is, and so on.
And then, naturally, you can get complexity just by building stuff on top of that big database server, and other things that depend on those things.