With out the language agnostic part of the interfaces, they provide nothing that an abstract class doesn't already provide.
Oh, no, with this I dissagree, they do!
They provide a way to define common behaviour for classes which do not have common superclass. It is a very useful feature, as multiple inheritance does not exist in Object Pascal and Java. The link which vfclists gave
(again, this one) describes that (see the first section - reason for interfaces).
In Java it is very much used, all over the standard java class libraries. In FPC and Delphi it is not used that much, I don't know why (a bright exception is ZeosLib - many functionalities are implemented with interfaces, I believe it is because Zeos is highly influenced by Java's JDBC library and they used their filosofy).
But in the case of your own locally developed code can you change the interface whilst retaining the same GUID so long as all the dependent code is available to be recompiled?
As far as I understand now, the GUID-s matter only for exporting them in dynamic libraries/shared objects. When used as a normal language feature (see above), you just don't need them.