Declaring values that would already have been assigned by the compiler is useless for the behaviour of the program. However, that isn't what you should be optimizing as a professional developer. Instead, you should maintain your code base in the state that best supports ongoing development.
If code were only about its semantics here and now, you could think really hard once, slam out the necessary assembler code and never think about it again. But in the real world, requirement changes, fixes, maintenance, format changes etc. etc. keep coming one after another without end. It is crucial that your code base not only does what it's supposed to, but also remains in a state that lets you do the ongoing work that will be required.
Spelling out things that would already be the default can be helpful for that, so it's not automatically a bad idea. After all, you don't pay the compiler by the number of characters it consumes. You should declare things when doing so makes the code more readable.
In Java, global variables are automatically initialized, but local ones aren't; depending on the experience levels in your team (your current team and the expected future team!) it may be a good idea to spell things out so nobody ever has to think, even for a second, what value some variable will have at run-time, or it may not be. But "It doesn't change anything in the compiled program" is not a sufficient argument to call code "useless".
if (someBool == true)
It drives me up the wall! Should I make a big deal of it or just drop it?"