I don't think the breaking point is the number of lines in the script; your pain point is probably one or two specific concepts or features? (or lack of) Shell

I don't think the breaking point is the number of lines in the script; your pain point is probably one or two specific concepts or features? (or lack of) Shell is likely to remain the best way to connect together other pieces of software. The tipping point, in my experience, is folks trying to use arrays or other buffering of data. At that point they're writing in shell, but wishing for a procedural language. Whereas, shell works excellently (and incredibly efficiently) if you can compose your task strictly into streams of data (a more 'functional' feel) So the real answer I think is specific to the types of script you are writing! But also it could be worth revisiting the style in which you're using shell; especially if you can call upon your own helper programs (eg. in Python) where you require buffering or non-streamed access to data. Whilst there's a lot of documentation of sh/bash functionality, I don't think there's anything like the same momentum behind 'best practices' as other languages like Python or even C.