Hmm, why exclude #4: Concurrency and Channels? Concurrency in Python is a nightmare; in fact, doing anything more complex than embarassingly parallel computation in Python is a nightmare. Goroutines are excellent for lots of application logic, especially if your operations are being blocked (e.g. querying a database and waiting for the response). I'll admit the difference is less large if you are doing big data computation / ETL where tasks are long-lived and you can eat the overhead, but the post was specifically for an application's web server.
Also re #3 and #6 - I found learning Go to be relatively painless, coming from a Python background. It was helpful to have much more experienced teammates and to have some opinionated pre-existing infra (e.g. tests, lint, deploy, general app architecture). The lack of frameworks is good/bad -- more decisions to make (though the standard Go libraries seem to almost always be good enough) but if everyone is mostly using some combination of modular libraries, it means that problems are easier to debug and search for on StackOverflow, versus needing to add if the error is in Flask or Django or some other bespoke framework.
Also re #3 and #6 - I found learning Go to be relatively painless, coming from a Python background. It was helpful to have much more experienced teammates and to have some opinionated pre-existing infra (e.g. tests, lint, deploy, general app architecture). The lack of frameworks is good/bad -- more decisions to make (though the standard Go libraries seem to almost always be good enough) but if everyone is mostly using some combination of modular libraries, it means that problems are easier to debug and search for on StackOverflow, versus needing to add if the error is in Flask or Django or some other bespoke framework.