This short book is great for starting developers, and intermediate developers will probably still find a couple of things worth learning. The first few examples are extremely basic, but I can see how they make sense for someone without much experience. They were also confusing/misleading (until the authors explain why a couple of pages later) because the improvements are still suboptimal (specially at the start); the idea being that they want to improve one thing at a time, and not overwhelm with changes for the comparisions.
Though I agree with almost all of it, I have a couple of disagreements, or at least remarks, e.g.:
1. They never mention the ternary operator. I think the first comparisons would have benefited further by use of it, leading to more concise and less repetitive code.
2. On page 9, they recommend extracting conditions into boolean variables to give them a name and improve readability. The suggestion is well-intentioned, but has the downside of computing more than is needed. One of the upsides of the boolean operators && and || is their lazy evaluation. A better solution would have been extracting the conditions to their own methods. You still give the condition a name, but can also reuse them in other places if need be, and you still get lazy evaluation. Note that this is something that affects languages with eager evaluation (which is the majority, including of course, Java), but extracting conditions into a variable would work perfectly fine in a language such as Haskell, since lazy evaluation ensures it won't be computed unless actually needed.
3. On page 10, they use string.trim().equals(""), as well as string.trim().isEmpty() later in the book. These are quite common, but they should mention that commonly used libraries (such as Apache Commons with StringUtils.isBlank()) have preferable (more readable and more performant) alternatives.
4. On page 13, they argue that switch statements should always have a default branch to fallback in case some new case is added and one forgets to update the code. They fail to mention that IDEs (at least Eclipse, maybe also the java compiler) have exhaustiveness checks for enums, and one can even fail the build in case there is a branch not covered by a switch. I think doing that is better than adding a redundant default case, which if ever useful, will still fail in runtime instead of compile time. (There are also switch expressions which must be exhaustive, but the book predates these).
5. The "Favor Format Over Concatenation" advice is also questionable. It's true that it's sometimes more readable--at the expense of being considerably slower, as well as sacrificing some safety: if you are mising an argument or have one too many (conversely, if you are missing a format specifier or have more than needed), the code will compile fine but cause an exception at runtime.
These things aside, and their not-so-favorable talk about static analysis at the beginning (although they do recommend using it by the end of the book), I'd definitely recommend this.