PEP 8 currently has::

  Yes::

      ...
      c = (a+b) * (a-b)

  No::

      ...
      c = (a + b) * (a - b)

That looks wrong to me -- surely the parens are a sufficient
precedence hint, and don't need further squashing inside?
This will be worse with any non-trivial example.  I suspect
it may also lead to silly complications in code formatting tools.

This was changed by Guido as part of a reversion in issue 16239,
but I wonder whether that example was intended to be included?

FWIW, this pair of examples differs from the others in this section
as they were both explicitly okayed in the first version of PEP 8
<http://hg.python.org/peps/rev/4c31c25bdc03?revcount=120>::

    - Use your better judgment for the insertion of spaces around
      arithmetic operators.  Always be consistent about whitespace on
      either side of a binary operator.  Some examples:

          i = i+1
          submitted = submitted + 1
          x = x*2 - 1
          hypot2 = x*x + y*y
          c = (a+b) * (a-b)
          c = (a + b) * (a - b)

My guess is that this is still the intention?

See msg173785.

The example in the "no" section is not "wrong" -- it's just worse than the one in the "yes" section because it provides less hints about the groups and it's less readable, so it has no reason to be used.

If you note the introductory paragraph it says "Use your better judgment for the insertion of spaces around arithmetic operators.".  This means that even if the general rule is to add spaces around the operators, in some situations it is better to omit them, and one should decide on a case by case basis.

To provide a further example, see:
  a = 2 * (b+c)
and 
  a = 2*(b+c) - 2/(d+e)

The first part -- 2*(b+c) -- is the same in both the examples, but the spaces change depending on the context.  In the first case you can emphasize the multiplication between 2 and b+c, whereas in the second case there are two "groups" that get subtracted, so the spaces around the * and / can be removed to emphasize these two bigger groups.

I think that section is OK, and doesn't need to be changed.

Style is a matter of taste, not of correctness.  It is pointless to debate the finer points in a bug report.