This answer only partly addresses your question.
Your logical position in the Ethereum network (i.e., which peers you have) will affect what you see as being the canonical chain at any given point. Due to the possibility of temporary forking, if you react immediately to a block, you should be ready to handle the block becoming "undone" if it is part of a losing fork.
Depending on your application, you may also wish to run many independent nodes and have your software capable of becoming eventually consistent so that you can be on multiple forks at the same time; this allows you to react faster to changes, regardless of which fork you hit. The chain considered canonical (for any instant) depends on which blocks you receive first. This means that not only do your peers matter (because different peers will see different chains as being canonical) but also your latency to the peers will affect which node
geth believes to be canonical. With only a few peers, bandwidth is less important than your latency/OS' ability to handle packets (1). Thus, you will only see one version of the blockchain with a single
geth instance when, in fact, there might be multiple versions at any given instant. As a result, you might actually run a few blocks "slow" relative to the winning chain if you only used one instance. For example, if you are on chain
A at block
x which contains transaction
a and you react to it and then chain
B wins at block
x + 1 and it contains transaction
b (also at block
x), then you will be one block late at handling the transaction. In fact, because more peers will have a non-zero impact on the performance of your node, if your goal is the fastest reaction time, it may actually be preferable to run more physical nodes with fewer peers each. On the other hand, if your goal is to propagate something out quickly, having many peers per node is probably helpful.
Thus, multiple nodes allow you to react to different versions of the blockchain as they appear. The likelihood of forking decreases with slower block times, but is still non-zero.
In addition to the time to receive a block, if you want to react as quickly as possible, you also need to process the new block; this means a fast CPU, probably with AES acceleration, and as fast a storage volume as you can include. I'm guessing lots of RAM for caching won't hurt either, based on a strategy for mitigating the effects of the attack that necessitated EIP150. The CPU speed and storage speed definitely matter for Parity (as reported by Parity's log output) and RAM starvation has negative effects. I couldn't tell you whether a high core count is preferable to a higher single threaded execution frequency, though. Maybe I'll post that as a question here, but it is possibly dependent on things like the contents of the incoming blocks.
(1) At 100KiB/block, transmitting a block on a relatively modest 100Mbps pipe takes 8ms (give or take). This is about the same amount of time as it takes a packet to travel the short distance of London to Paris with a direct route.