Definitely enhancement, not sure if I want to implement it, because it's a logical nonsense... Ifaces can't have properties, sorry ;) But I'll discuss it with my colleague.

Let me give you some more pro's for this:

Magic properties are, strictly seen, just syntactic sugar for getters and setters; most people use them to reduce coding overhead and it becomes particularly useful on auto-generated code (ORM layers like Doctrine 1 do it a lot). You are allowed to define getters and setters on an interface, so why not magic properties as well?

It's possible to define __get/__set on an interface to force the implementing class to provide the magic methods. There's no other way to assure which properties these magic methods have to take care of, so adding @property on the interface at least gives the programmer a hint.

Some project follow an "every class has its interface" paradigm and use only the interfaces as typehints; this allows better dependency injection and unit testing, and would help to mimic the missing package/namespace scope of PHP (public methods of a class not defined in the interface are of package scope). To allow those projects proper reflection in the IDE, the @property must be defined on the interface level.

Finally, phpDoc states explicitly that @property is supported on classes _and_ interfaces. (uhm... what about traits...?)

Just because something is allowed, doesn't mean it is good, e.g. LSB, multiple paradigms, type juggling, etc. in PHP
Magic methods also are undesirable.