It's used by editors like Visual Studio Code to provide intellisense, autocomplete, breakpoints and the like.
The idea is that instead of each editor writing it's own (incomplete) Python or Go plugin, someone writes a language server which is then used (and improved) by everybody.
To add to this: the beauty of the protocol is that it uses JSON over stdin/stdout for communication. So if your language can make console apps, you can write a language server in it that works with any compliant editor/IDE - no FFI necessary, no need to learn how to author extensions for that editor etc.
And, conversely, if your editor/IDE can fork a child process and redirect its standard streams, you can support any language server and not care about how it's implemented.
I think this more than anything else has contributed to its rapid adoption, especially on Unix-likes.
The protocol itself is transport-agnostic - it just needs a bidirectional stream, and the spec doesn't define what it is. In practice, both stdin/stdout and sockets are used - the latter usually for language servers that are "heavyweight", such that it is advantageous to spin up the server once, "prime" it (let it do any indexing etc), and then reuse it between concurrent sessions. The standard streams are usually the default choice for simplicity reasons, though.
Implementing a server in Brainfuck is theoretically possible, but only if you ignore the heat death of the universe as the upper time boundary. ~
mdempsky's fork of gocode should work with Go 1.11...
and rstambler's fork of that fork (https://github.com/stamblerre/gocode) should work with modules.
* edit: mdempksy's fork should work with Go 1.11 used outside of a module or with GO111MODULE=off; Rebecca's fork adds support for modules on top of that
