ktlint-gradle is still very popular, so EOLing it would put a burden on all of those people who use it to migrate. now, you might say "we have no obligation to keep maintaining it for their sake". Fair. However: I literally do, since I am responsible for gradle JVM tooling at my company. ktlint-gradle is used heavily there. if ktlint-gradle became unmaintained, we would be more likely to just create an internal fork of it than migrate to something else, at least for awhile. And I would probably be the one to create and maintain that internal fork. So for me, I might as well just do the work to keep the OSS ktlint-gradle going, as its probably less work for me, in the end.
one other point: we have done one thing in ktlint-gradle that ktlinter has not, which is maintain compatibility with multiple versions of ktlint even through the breaking API changes. you can currently use ktlint-gradle with ktlint 0.34-0.48, where as kotlinter currently will only work with ktlint 0.48+. This gives teams flexibility in when they upgrade their ktlint version according to when they have the time to address any changes, but still keep up to date with the plugin to ensure gradle version compatibility and such. It also exposes the ktlint version configuration in a much better way.
This is just my personal take on why it is worth it to keep the project going.