For an individual, making sure you space several times instead of tab, or use one return statement per function instead of several can be time consuming and frustrating. However, unless you’re working on a project alone, coding standards are imperative to success and organization. Sure you may understand what you wrote (albeit in some cases it may take a bit) but to be a software engineer is to work with others. When time is always, important structure helps engineers communicate effectively. Trading code between people who are use the same format makes it far easier and clearer to understand. It’s not so different from people who speak the same language with starkly different accents; sure the underlying meaning and language is the same, but one may have trouble understanding, especially on difficult topics.
What truly makes this possible though are IDEs. Without an IDE to help speed up the process and have templates for coding standards integrated, such as the combination of ESLint and IntelliJ, the time cost of manually formatting may outweigh the gains. Fortunately for all developers that is not the case; there really is no excuse not to implement formatting standards as the code can essentially format itself.
Striving for cohesion and structure is not a new concept either, it’s true for any great team. Even though there are a number of key aspects of formatting that isn’t covered by ESLint (to my knowledge) a key example being naming conventions; having the basics covered by tools like ESLint imply higher level structure as well. A sub element of standards is the enforced discipline; quite similar to the military there is a level of enforced self regulation which contributes to the cohesion of the overall team. The overall strength being that if you have a number of engineers who can communicate seamlessly, the brainpower and limits to what can be created by that team becomes amplified.