As always, writing style is only a means to an end (in technical writing, at least), so there exist no rules that must always be followed. Still, there are some general ideas that lead to good writing. I'll provide an analogy from Software Engineering.
In Software Engineering, we have the concepts of cohesion and complexity of a piece of code, let's say a function. A function is said to have high cohesion if all relevant parts to some task are handled by this function. This is considered good, as the reader only needs to read this function to understand the execution of a task.
A function has high complexity if it is big and/or nasty, i.e. difficult to read. This is considered bad.
When creating a function, you must sometimes be careful to make the function not too complex while remaining cohesion. The same can be said of writing: your piece of text is most understandable if all relevant information is in one place (in this case a sentence, but we can also consider this on the paragraph level), as long as it isn't too complicated to read.
I see two reasonable approaches here:
Maximize cohesion while keeping complexity under a fixed 'limit'. This means writing long sentences when you can, i.e. when they can be understood. This is the approach that I personally seem to employ. (I don't consciously look at the length of my sentences unless they are way too big)
Minimizing complexity while keeping the cohesion above a fixed 'limit'. This means writing sentences as short as you can afford. A risk of this approach is that you sentences get too much 'communication overhead': if you have a lot short sentences, you must indicate the relation between those sentences. If that 'glue' has the size of half the length of your sentence, readability is at risk.