See also #39 (comment).

The code is only partially framerate independent.
Increasing FPS makes the simulation run more often, decreasing FPS makes it run less often.
The overall behavior might be mostly identical but it will be sped up or slowed down respectively.
For example, if the rope swings one time back and forth in one second at 60 FPS, it will do the same in only 0.5 seconds at 120 FPS.

Some parts of the simulation are FPS independent, like gravity or damping which lessens the effect, but this is not the case in general.
The main issue making the simulation framerate independent is that velocities are determined using the position difference from current to last frame for each rope point.
That means, the farther rope points are moved in one frame, the higher their velocities will be in the next frame and the stronger the reaction.

In contrast to common Euler based physics engines, the plugin does not continuously integrate forces to handle velocities. It recomputes velocities every frame from the current state.
This has the advantage of a very simple and efficient implementation.

Imagine we would multiply velocities with delta when computing new point positions.
On higher framerates, the rope points would move less because of smaller deltas, on lower framerates they would move more.
Instead of making the simulation framerate independent, delta would only act as a kind of damping factor, because it only slows the movement down, which in turn affects the velocity computed in the next frame.

It's perfectly fine to use this plugin on other framerates than 60, but you will get different behavior.
If it works for your use-case, that's fine, feel free to remove the line producing the warning.
But be aware that you can't just switch framerates and expect the same outcome.