The

    "editor.codeActionsOnSave": {
        "source.organizeImports": true
    },

is basically a temporary hack, while we decide what the correct user interaction really is.
You are correct that fixing imports is related to the squiggles (note that those are not lint errors btw, gopls does not do linting yet, they are type checking errors).
This is because fixing imports is done as a code action associated with the diagnostics that tell it the code is currently incomplete. And yes those diagnostics are asynchronous because we do them as you type and do not want to slow the user down.
We are trying to decide what the best approach is for the user, I generally dislike doing things that might be expensive on save, but if we want to do that we need to move fixing imports to the willSave call. I think in general it will be better to fix imports as you type, but then the question is should it be automatic, or a quick fix activation. Should we fix all imports at once, or just the one for the symbol you activate the fix on.
Input is welcome from anyone that has an opinion on the best possible user interface for managing imports...

Well, I mean, basically everyone in the world uses goimports on save right now, so, I guess it's fine, speedwise? Certainly I've been using it forever and it seems fine.

There are definitely people for whom it is not fine speed wise. For a file that is fully satisfied it is always very fast, but once you start having to look for new imports it can get ugly. This is especially true for people not using the go tool as their primary build system.
There are some interesting/ugly edge cases where you either have to just give up or take a very long time, neither of which is very palatable (my definition of long time might not match most peoples though)
Also there are also lots of people that do not want to use goimports, they use goreturns and gofmt -s and a bunch of other things, I would like us to be able to allow users to have the union of these tools, not have to pick just one.
I think we are all used to save hooks because they were easy to add, not because they are the best way, and I would like us to take some time to think what the best way truly is. If it turns out that save hooks really are the that way, then we will add the handling to textDocument/willSaveWaitUntil but that message comes with the caveat that if you take to long to calculate the edits it stops waiting for you, which is the right choice for users but will result in exactly the behavior you are currently seeing where if you safe fast enough after and edit and we cannot work out the new import quickly enough it will save without the changes.

Just chiming in to say that the latest version of gopls do not actually wait for diagnostics - they run on save. @natefinch: do you still see this behavior with versions of gopls after https://go-review.googlesource.com/c/tools/+/172406?

Oh sorry, forgot you said you were using the latest versions as of the time you opened the issue. This seems to be just a case of this code action not working fast enough. As @ianthehat said, we are still working on a better approach for this.

At this point, it seems like we're sticking with import organization being a code action in gopls. A lot of work has been done to speed up import organization in the latest version of gopls, so I think we can close this issue. Please open a new issue if something else comes up.