Thats a good point, but I've always found the killer app for big O notation is something the answer claims is wrong impossible:
"You can't compare an algorithm to do arithmetic multiplication to an algorithm that sorts a list of integers."
I rarely if ever implement just a multiplier or just a sorter. I end up implementing systems. And if everything in the system is linear or small poly but step #7 is exponential, then comparing Big O for unrelated algos is extremely valuable for me to estimate how long the overall system is going to take and where optimization effort should be placed for best improvement, etc. Don't waste time on making something linear a little faster, when I could be trying to refactor something exponential into something merely poly, somehow (assuming its even theoretically possible per some big O evaluation). Or refactor the whole system to be only poly.
"You can't compare an algorithm to do arithmetic multiplication to an algorithm that sorts a list of integers."
I rarely if ever implement just a multiplier or just a sorter. I end up implementing systems. And if everything in the system is linear or small poly but step #7 is exponential, then comparing Big O for unrelated algos is extremely valuable for me to estimate how long the overall system is going to take and where optimization effort should be placed for best improvement, etc. Don't waste time on making something linear a little faster, when I could be trying to refactor something exponential into something merely poly, somehow (assuming its even theoretically possible per some big O evaluation). Or refactor the whole system to be only poly.