The numbers are not meant to be accurate. It is the ratios between the orders of magnitude between tiers that matters.
However, when a disruptive technology appears (e.g. cloud computing, 10GB/100GB ethernet, new networking kernel module, SSD storage networks, virtualization and containerization), these numbers can be invalidated due to new tiers appearing, disappearing, or being shuffled around.
When programming at a very high level - where all of the computation, networking, parsing, etc., are performed using libraries not written by yourself, knowing the performance figures of low-level operations may not help much, since your opportunity to improve each library's performance is rather limited or outright impossible.
Instead, read the performance-related documentation of each library carefully. If a library does not come with those, ask them - make it an issue. Or learn how to benchmark software in the correct way.
Having a basic understanding of latency numbers is important when you are hired by a company that designs and manufactures software components. Compare that to a company that designs and manufactures cars and every component contained within - the proverbial "reinventing the wheel" (rubber, tire pressure, treads, etc.)
Most software companies do not work at the component level - entire functional software systems can be constructed from putting components together. These software companies do not need to focus on how to engineer components in terms of latencies; instead they need to evaluate the quality of the components they choose.
To summarize, (1) it is very possible that you don't need to know the latency numbers; (2) unless you want to be hired by a company that makes software components (libraries), whether for sale or for internal use (as in some of the largest software companies in the world), (3) if you need those numbers, it is your job to do the benchmarks yourself, in a scientifically correct way, or else you shouldn't be working on software components.