It is true that knock on effects are a thing, and small fixes can sometimes have suprisingly big returns. However most small fixes do not, especially in programming. The art of optimizing is understanding the problem well enough to find the right 1% speed improvement to make, because you cannot do all of them and most don't.
What i took away from the article (after all the obnoxious long winded irrelavent tangents that went nowhere), is basically dont dispair if the fixes look small because you might accidentally stumble upon an important one that isn't small without realizing it. Which i find to be a depressing, two wrongs sometimes make a right, take.
If Donald Knuth suffers from this as well then I wouldn't berate myself too much about it, his famous quote that 'premature optimization is the root of all evil' then you're more than excused to let optimization rest until the code is correct (which is far more important than that it is fast) and then use a profiler to tell you where to most efficiently apply your attention. This will get you to a very high percentage of the optimum in a relatively short time.
There's a whole story (about a criminal api venture) where the point is stated that speed-ups that look pretty small have knock on effects that allow for opportunities elsewhere, and that these opportunities snowball until something significant happens.