If a library works like it should, then you may never have to look at it - that's great. But if you're working on a team, you'll have to read and understand other people's code all the time, and even if you're not, someone, somewhere, is going to eventually want to make that library do something different.

I agree that, of the two, good test coverage is more important than pretty formatting, but a good code style is going to make the code easier to debug when those tests fail and easier to extend when the library needs to do more. It's a simple matter adopt a coding style that works and stick with it, so there's really no good reason not to do it.

By comparison, it does seem like a trivial thing to obsess over. There are a number of coding styles which are all fine in their own right. I think people should worry less about the specifics and more about the overall intent-to write consistent, clean code. How many blank lines you have after block of code or where you put the opening bracket doesn't really mater in the end, as long as you follow the same structure across the whole code base.