It's possible that the warnings are incorrect in the specific cases. If you post a relatively small test case, I can tell you more.
Just thinking about this a bit more, the warning is correct: operator->() does only make sense with a class or struct.
However, I can see this warning generating quite a lot of noise in the case of templates that can be instantiated with either classes or built-in data types, and which support both operator*() and operator->() for some sort of dereferencing-like behaviour.
I guess it's fair enough to leave this warning as it is, but I'll probably end up switching it off to reduce build log clutter. This is the sort of occasion where the -isystem option of gcc and clang is great. -isystem is similar to -I but tells the compiler not to report warnings in the included files. That way I can leave all warnings enabled in code I own but ignore them in 3rd party code. I know other compilers have pragmas and other options for doing this sort of things, but I think -isystem is by far the simplest for the case where code can be divided into "owned" and "3rd party". It would be great if you could consider something similar for a future release.
It's possible they did something similar to boost::format's use of operator%; perhaps operator-> was overloaded to make the interface they came up with do something that while not immediately intuitive (and potentially questionable), is at least intentional on the part of the author -- hence it's a warning instead of an error.