First: of course it's generalizations. "How to write a program" advice is never about hard rules and is ususally some generalizations and heuristics that when applied well can result in nice programs. When over-applied or treated as hard rules you end up with FacadeFacoryFactories and other such absurdities.
Second: From an SE perspective it has some nice properties too. Obviously every "if" can't be moved up - even the for's that are being pushed down have an implicit "if". But when you try to follow the advice without making the code too crazy, you end up with business logic clustered in a much smaller number of places, and don't have to dig down into a leaf function in an unrelated module to find out why the some transaction was being rejected (aka the accountants said that qty > 100 was not allowed or whatever).
Second: From an SE perspective it has some nice properties too. Obviously every "if" can't be moved up - even the for's that are being pushed down have an implicit "if". But when you try to follow the advice without making the code too crazy, you end up with business logic clustered in a much smaller number of places, and don't have to dig down into a leaf function in an unrelated module to find out why the some transaction was being rejected (aka the accountants said that qty > 100 was not allowed or whatever).