This is really subjective, but I guess general Software Engineering best practices apply, as scripts are really self-contained, usually representing a single instance you would only benefit from splitting it if it could be reused elsewhere.
I guess the real answer is probably when you find it too hard to maintain or to find what you’re looking for.
My game’s player controller is about 700 lines long, but used to be much more. Unless you plan to re-use some of it, it doesn’t sound necessary to split it. There are ways you can make it more terse though, by factoring similar code into functions or variables.
But even if you don’t use a part of your code anywhere else, another reason to extract some of it is to keep mind sanity. A large part of my logic used to be related to a generic concept, which was unclear when I had it merged together with all the other stuff. It makes it harder to isolate bugs when they happen, so I separated the feature to make it work alone, then just referenced it in the main script. After doing that several times I ended up with 700 lines purely executing the game’s core player logic, the rest being delegated to more independent scripts (audio, visuals, ground detection, achievement detection, debugging, pickup detection etc).
On a larger scale, if you keep “plugging” new behaviours that don’t inter-call themselves too much, you could use a component approach, or even a state machine to keep it organized. But you know, some people are just fine with 5000 lines
