When you try to translate a text from one language to another, you are often faced with words that have no exact translation. The exact concept does not exist in the receptor language. So you have to make do with an approximate translation, either keeping the nuances that you judge to be more important and reluctantly dropping the others, or writing long, cumbersome sentences that cram in every notion you can think of, at the cost of the entire disappearance of the original elegance of style.
When you try to write a mathematical proof, it's a little bit of the same process. You have an idea in your head, an organized ensemble of mathematical notions, and you try to communicate them with symbols and English words, but what is written can never be exactly what was in your mind, and you have to make compromises. Sometimes you can spend hours, no, days, going back and forth: "I want to say this first. But then, that forces me to make a certain other choice. And then, there are further consequences. Oh well, at this point the changes are extensive and overall I am not sure I gained anything; I lost that other aspect that I really wanted to convey...", and it is really easy to go around in circles.
That's where our training in runtime and tradeoffs between efficiency and approximation ought to come into play! We can use hard constraints on runtime: "I will stop writing and send out what I have on Friday, regardless of how far it is from perfect"; or on quality: "As soon as the proof is written in full detail and hangs together with no gaps, I will put it on arxiv, even if it's unnecessarily cumbersome". Soft constraints are dangerous: "I will stop tinkering with the paper as soon as I see that an extra day of work does not lead to any significant improvements". When co-authors have different standards, it can lead to tensions.
The better written it is, the more readers there will be. In the limit, if it's perfectly well written, which takes infinite time, then everyone will read it.