checkstyle is the same, I believe. But there I understand why, because it's bundled with gradle it has to provide a way to utilize older rules configuration with newer checkstyle to avoid breaking the checks when gradle is upgraded. With detekt I do not see the rationale, maybe one of the authors would like to comment.

Interesting thought! Seems like a bit of a stretch though. What's the chance that the gradle config would change in a way that's not backwards compatible, but the interface the plugin uses to talk to detekt remains backwards compatible?

There are not that many changes to the gradle plugin then to detekt-cli. Half of detekt's version could have been released without a new version of the gradle plugin. Don't know yet if we should always update the gradle-plugin just to be on pair with the version scheme 🙂

I suspect that that's a pretty common situation for plugins that depend on underlying tools. As long as the interface to the underlying tool hasn't changed, the actual code of the plugin doesn't need to change, but I think many plugins release anyway, just to simplify version management.