And it's the wrong math. You claim that increasing latency will necessarily decrease bandwidth, and that is simply not the case.
If we assume that there are a fixed number of packets in flight at any given time, and we increase the flight time of all packets, then it will be true that the packets-processed-per-time will drop (and ceteris paribus that the bandwidth would drop). This assumption, however, is incorrect. One could (in theory, and within limits in practice) add extra pipeline steps to do extra processing, increasing the time taken to process each packet, without decreasing the rate at which packets traverse the processor (e.g. the router). This is hopefully what happens.
Of course, as I and others said elsewhere, it is OFTEN the case that as processing-per-packet increases, this becomes a bottleneck on packets-per-time, and this does eventually limit the bandwidth. (Jumbo frames sometimes help, but not if the processing is being done on the entire application payload, which of course is what DPI does, so jumbo frames ain't gonna help there.) So in practice, more DPI might well decrease bandwidth.
If you would like an analogy, imagine the hosts are cities, the packets are trucks carrying goods, and the route is a highway of fixed speed limit and width. (Yes, one weird thing about this analogy is that building new trucks is basically free and done on-demand.) Suppose we consider shipping an infinite amount of coal from city A to city B. The number of tons of coal shipped per day does not depend on the length of the highway. The amount of time it takes for each ton of coal to get there DOES depend on the length of the highway. Coal-per-day is like bandwidth, hours-per-truck-trip is latency. You can increase or decrease one without affecting the other, all else being equal.
Note: really, I shoulda done that example as a series of tubes, oh well.