Well really you are more right than me. It is about complexity more than the number of lines. However for the most part the longer something is the more complex it is to work with even if it does something simple. Managing a 1000 line bash script is almost certainly going to be more painful than doing it "properly" in Python or Java or whatever.
It mostly comes to do this for me "is this thing going to be something I need to understand and manage outside of my own little bubble?" if it is then I want it to be better designed/maintained and I find that gets easier as I work "down the chain".
Thanks for taking the time to reply. And you're right, even I wouldn't want to maintain 1000 lines of serially-executed commands, meaning I have a line limit somewhere as well. So maybe a mix of complexity, and at some point length even if I don't put a number on it like you did.
Scripting on Unix is a lot better but it is only recently that places seriously use VCS for scripts in my experience so before the days of Git if you wanted to do anything with an iota of manageability it meant you did it in a "real" language hehe.
So for me, it's not a matter of LoC but complexity. Need to copy file from here to there, then commit to git repo, blah, blah, blah, then kick off a build? Whether it's a 1000 lines or 2, I don't have a problem with doing that in bash. But as soon as I need some logic (or on rare occasions, perf), I go to something else.
Given that, why do you cut shell scripts off at 20 lines? I ask in the spirit of being open to the possibility that maybe I'm doing it wrong. :-)