Unfortunately, Black Hole, it isn't visual; the slabs are actually getting pulled.

While we get that point, the issue here however is that without doing it this way a lot of protection plugins would break.
In this case it was decided to do it this way in order to keep some plugins working while breaking others.
Regardless of the decision, the plugin above mentioned would of broken anyway.

That is only a visual glitch. If you relog you'll see that no border block was actually pulled.

That seems like it would cause some issues with older plugins. For instance, PlotMe 0.13f (which is the latest version available on spigotmc.org) doesn't take any of this into account and players can pull the plot borders back.

Using git-Spigot-116e6fc-54888df and PlotMe 0.13f, this is what will (but shouldn't) happen:

Before
During
After

This should technically be prevented, but it isn't.

Even though a plugin like PlotMe will eventually be updated to fix something like this, I'm sure there are some plugins that fall under this category which will not be updated.

The BlockPistonRetractEvent now only handles if the piston should retract. If you cancel that event, no BlockPistonExtendEvent will be fired. If you don't cancel the BlockPistonRetractEvent, you could still cancel the BlockPistonExtendEvent, so the piston would be retracted but no block moved.
So this "works as intended", but the JavaDoc needs to be updated.

Hmm correct, sorry, I was under the impression they were not included in this event.
I will look into this.

Edit:
It seems that for compatibility reasons a BlockPistonRetractEvent also fires a BlockPistonExtendEvent which does include the blocks.
Essentially the BlockPistonExtendEvent was turned in to an BlockPistonMoveEvent.

That hasn't been true since slime blocks were added.

A sticky piston only pulls in a max of 1 block. And the event does include that block.

see: http://jd.bukkit.org/rb/apidocs/org/bukkit/event/block/BlockPistonRetractEvent.html

specifically, the function getRetractLocation().