Nobody seems to be able to agree on where whitespace makes source code more readable, and where it achieves just the opposite. The same holds true for the question where all those curly braces should be placed.
Whether a curly brace on the same line or on another line makes source code more readable, is indeed a very subjective feeling. It is important to format code consistently across teams, however, especially when IDEs are used. They love to "correct" whitespace, for instance by replacing tabs by a configurable amount of blank characters. Changing Windows to Unix line endings – or vice versa – is the same story.
If a project uses different IDEs, or different IDE configurations, this often leads to commits to version control where every single line is modified, even if the developer only changed a few lines directly. This makes it hard to spot the relevant changes in the project's change history.
It is secondary how source code is formatted, but it is essential that all code is formatted consistently. It is equally important to make sure that everybody adheres to the formatting rules, and to do this on a regular basis in an automated way. You can use tools such as PHP_CodeSniffer, and run them as part of your Continuous Integration build chain. Without automated verification, developers will just pretend that they adhere to all rules, probably even to the best of their knowledge.
Every development team thus has to agree on one uniform coding standard. It should contain a lot more than just rules about source code formatting, for example conventions on how to name identifiers, or a list of forbidden language constructs (no use of static methods, no Singletons, ...).
Should a development team not be able to agree on a uniform coding standard, this is an indicator for a fundamental communication problem inside the team. A communication problem that is mirrored in inconsistent formatting of source code.