I've never used Fluid with sockets, so I'm trying it out now.
What you're doing really is nothing to do with Python (I don't think), so we can simplify it just by running it on the command-line, and using netcat (or telnet) to communicate over the socket:
$ fluidsynth -sli -g0.5 -C1 -R1 -a alsa -j /usr/share/sounds/sf2/FluidR3_GM.sf2
(in another window)
$ netcat localhost 9800 quit
This should be running exactly the same process and performing the exact same socket communication as your Python example, but without the need to worry about subprocess and socket libraries.
When I do this, I see the "cheers!" response in the netcat window, and then netcat terminates. I don't see any output in the FluidSynth window, and it doesn't terminate (in fact, I can open another connection -- in fact, I can open two simultaneously!)
So it seems like when you use Fluid's network interface, it doesn't quit itself. It closes the socket. This seems sensible to me. FluidSynth is acting as a network service. It's giving the client the illusion of being at a FluidSynth console, and if the client wants to log out, they type "quit". It wouldn't make sense for the client to be able to shut down the network service, any more than a web browser can kill a web server by closing the browser window. So I think FS is behaving correctly and sensibly and I wouldn't imagine there was a way to remotely shut down the server (though I may be wrong about that).
It makes sense, though, in your situation, to want to do that, since you are the one that started it in the first place (with subprocess). So, I guess I would ask why you are using sockets at all, instead of using the subprocess stdin socket? (Obviously, without the -i argument). Then it will close when you quit, as you say. Alternatively, if you need to use sockets, just detect when the socket closes (as Fluid will automatically close your socket when you "quit"), and then call the terminate method on the Popen object returned by subprocess.Popen.