If it doesn't use gopls, then it will probably break in every corner case like previous tools did. When modules first came out, you had to go like 3 forks deep in "gocode" (the previous completion provider) because the original author stopped caring at go 1.10, then the person who forked that didn't support modules, then finally the author of gopls started maintaining it. This maintenance overhead was exponential, given that gocode was not the only editor integration; syntax highlighting, godef, etc. all had to be tweaked for every editor and every go release. Now gopls handles all of this and is maintained by the go team itself, so it will support new features in the go language at the same time as go.
(I believe even dedicated go IDEs like goland have always been a little behind go itself. It simply doesn't scale to have every editor implement their own go tooling.)
gopls also addresses interesting corner cases. Say you build your project with Bazel, and you generated protocol buffers as part of your build so that developers don't have to find the right version of the protobuf compiler, install it, and then debug why changing one name in the proto file caused a 600 line diff. gopls and go itself can't know that you are generating some Go files with a build tool, so Bazel projects will have squiggly missing import underlines below your proto imports, won't be able to tab complete, and godoc won't be able to show you documentation for the protos. But, there is a solution; the "package listing" functionality is modular and can have a "driver" set at runtime, so all the go core tooling CAN find these generated files and treat them as though they were natively checked into your repository. It is reasonable to write one plugin for your build system to support Go tools, but kind of insane if every Go editor had to do this. gopls exists to make this work.
So with that in mind, every Go editor should be about the same. If you want new features, add them to gopls. If you are writing a new code editor today, just support the Language Server Protocol and you get great Go support, and support for every other language. https://langserver.org/ contains a list of supported languages, and it's pretty much everything. Last I looked, even things like Arduino were moving to LSP.
So I think the age of editors-for-a-language are over. Even if you restrict your focus to just one language, which isn't that useful to begin with, you will always be behind for some reason, be it new build systems, polyglot apps, new language features... it's not worth it. Just use LSP and focus on core editing.