The utility summarizes its entire remote-substation address space as a single route advertised toward its WAN transport provider so the provider's routers don't need dozens of individual entries. If one substation subnet inside that summary is temporarily decommissioned, why would an engineer add a blackhole route for just that subnet on the FortiGate, rather than leaving it unhandled?

Once a subnet is folded into a larger advertised summary, any router along the path — including the FortiGate itself, if the summary route also exists locally — will match traffic for that subnet against the summary and forward it accordingly, even after the specific subnet is decommissioned and no longer has any real destination behind it. Left unhandled, that traffic can be sent back out toward the WAN provider, which may return it toward the utility again, producing a routing loop that consumes bandwidth and can mask real reachability problems. Adding a more specific blackhole route for exactly that subnet causes the FortiGate to match on the specific entry first, by longest-prefix match, and discard the traffic locally instead of forwarding it anywhere. None of the other options describe a real function of a blackhole route: it has no interaction with FortiGuard threat-intelligence visibility, no effect on SSL deep-inspection CPU usage since inspection only applies to traffic that is actually forwarded through a policy, and no relationship to IPsec phase 1 negotiation timing, which is governed by tunnel configuration, not static routing. A concrete check is to send a test packet to an address in the decommissioned subnet and confirm it is dropped immediately rather than showing multiple hops toward the WAN provider in a traceroute.