Some languages have a very strong idiomatic style—in Python, Haskell, or Swift, the same code by two different programmers is likely to look a lot more similar than in Perl, Lisp, or C++.

There's an advantage to this—and, in particular, an advantage to you sticking to those idioms. It means that whenever you do violate the idioms, that's extra meaning in your code for free. That makes your code more concise and more readable at the same time, which is always nice.

In Python, in particular, many of PEP 8's recommendations are followed nearly ubiquitously by experienced Python developers. (Certain domains that have their own overriding recommendations—NumPy-based scientific and numeric code, Django-based web applications, internal code at many large corporations, etc.—but in those cases, it's just a matter of some different idioms to follow; the situation is otherwise the same.) So, it's worth following the same recommendations if you ever want anyone else to read your code (whether because they're submitting patches, taking over maintenance, or helping you with it on StackOverflow).

Example

One of PEP 8's recommendations is that you test for empty sequences with "if not seq:". But occasionally, you have a variable that could be either None or a list, and you want to handle empty lists differently from None. Or you have a variable that absolutely should not be a tuple, only a list, and if someone violated that, an exception would be better than doing the wrong thing. You can probably think of other good cases. In all those cases, it makes a lot more sense to write "if seq == []:".

If you've followed PEP 8's recommendations throughout your code, and then you write "if seq == []:" in one function, it will be obvious to the reader that there's something special going on, and they'll quickly be able to figure out what it is.

But if you've ignored the recommendations and used "if seq == []:" all over, or, worse, mixing "if not seq:", "if seq == []:", "if len(seq) == 0:", etc. without rhyme or reason, then "if seq == []:" has no such meaning. Either the reader has to look at every single comparison and figure out what you're really testing for, or just assume that none of them have anything worth looking at.

Of course you can work around that. You can add a comment, or an unnecessary but explicit test for None, to provide the same signal. But that's just extra noise cluttering up your code. If you only cry wolf when there's an actual wolf, crying wolf is all you ever have to do.