The schematic doesn't include nat/INPUT, which is between mangle/INPUT and filter/INPUT. Look at the end for the probable reason it's missing in the schematic.
nat/PREROUTING will apply before the initial routing decision, for all cases (routed, or for local endpoint traffic), nat/INPUT will happen after the initial routing decision, only if traffic is deemed local.
The way it's implemented in relation to routing and connection tracking, before routing, with nat/PREROUTING, you're allowed to change what will affect routing: the destination (
-j DNAT), but not the origin. After routing, with nat/INPUT, that's the opposite: you can't change the destination, but you can change the origin (
You have a certain inverted symmetry with nat/OUTPUT (which is on the schematic) and nat/POSTROUTING: nat/OUTPUT is only for locally initiated traffic and can alter routing decision, like in nat/PREROUTING, thus can alter destination (with
-j DNAT), second is for all traffic, routed or locally initiated, after any routing decision was already done (and can change source like nat/INPUT with
To answer the question, nat/INPUT didn't exist until it was needed. It was specifically created to handle new emerging cases avoiding requiring namespaces but using conntrack zones instead. It appeared in 2010. This link includes usage examples having motivated its creation, but it's quite difficult to grasp since it uses conntrack zones (which allow to separate totally identical flows (same 5-tuple protocol,saddr,sport,daddr,dport) into different conntrack entries by adding a zone tag on them. For example for special policy routed traffics, one arriving from eth0 going to eth2, the other arriving from eth1 going to eth3, or as in the first link to loop back traffic and track/nat it separately).