Go is popular because it is accessible. The cognitize load of the language is in effect ammortized by being spread over the life cycle of the dev process (i.e. run vet to do x) instead at localized in cycle/space of code-time/source-code, so even professionals not bothered by complexity can see an incentive to using the language.
But I am not aware of the language enabling a class of software systems, etc., that have become more feasable because of the language.
As has been pointed out by many, at some point even the novice programmer has to get serious given the mix of pointers and channels and sync constructs which demands a degree of sophistication, so the accessibility aspect degrades over time.
And then -- and here is why I feel there is pushback regarding Go koolaid -- this somewhat on 'the fence' approach of the language towards concurrency (originally "communicate don't share memory") gives this impression of a glorious hack but a hack aspect to this "revolutionary mix" that you refer to. At some point, the ala cart type system of Go presents issues to people who have invested the time to get serious about these matters but find that their favorite light-weight language is not fully up to the task of keeping up with our conceptual models of thinking about our software.
One of those runtimes is Ruby (Ruby uses lightweight threads, not OS threads), and Ruby is not a new paradigm.
Up through 1.8.x, Ruby used N:1 lightweight threads (multiple lightweight threads on one OS threads.)
Go uses M:N threading (multiple lightweight threads, which may be distributed among 1 or more OS threads.)
M:N threading is a different model than either the Ruby 1.9+ model (1:1 threading on OS threads with a global lock) or the older Ruby approach (N:1 threading), or even the JRuby approach (1:1 threading on OS threads with no global lock.)
For further proof of my point, I submit the fact that you are basically correct, yet those technologies never took off, even in their own communities. The dominant way all the scripting languages are written are as single threaded code, and the second most popular way is as event-based code. It's not easy to bolt that stuff on ten years after the fact, which is what most of those technologies did.
Lua would probably be the better thing to cite as the possible counterexample, in that it does seem like a lot of the people using it are at least using coroutines, though I believe it is not possible/feasible to get them threading in any nontrivial way.
(I'm not taking the out of claiming dynamic typing counts as a "new paradigm"... probably the single largest true programming change in the last 20 years is the mainstreaming of dynamically-typed programming languages. Which I think was still a good thing for static languages because it raised the competitive bar for them; I've personally swung back over to static typing, but the easy of the dynamic world has pushed the static world to greatly improve its cost/benefit proposition, in both categories. If my only choice was dynamic typing or what we had in the 1990s, I'd still be in the dynamic world.)
As a final postscript, may I observe that while I think that Go was a modestly revolutionary combination of concepts, I consider it an indictment of the programming community that it did not happen sooner. I don't see Go as if it somehow won a big race by being the best... I see it as a situation where it's the first thing that bothered to show up, years late, somewhat desultorily.
I'm ok with the Algol part as it pertains to syntax.
Semantics and expression though, is another thing...
You may complain that programmers have a professional obligation to learn those new paradigms. You may complain that programmers should consider "learning a new paradigm" a smaller strike against a language, especially if it brings other good things with it. But that won't change observed reality, in which programmers do want to not have to risk several months to a year on something they aren't sure will pay off. By contrast, if you know any of the existing manifestly-typed languages at all (Java, C, C++), which most programmers do to some extent, you'll be writing fancy concurrent code in Go next week. Possibly even "tomorrow". You can be shipping production code in a month.
The language nerd in me really wishes Go had isolated its goroutines from each other and only passed things by value. (While I like Rust's much finer-grained handling of that for a lot of other reasons, you can get a lot of the benefits in a language where the threads aren't supposed to be that large by isolating to small threads, and it's way easier to implement.) The pragmatist in me is forced to reluctantly admit that had it done so it probably wouldn't have succeeded as much, because while that may not have been a "full" paradigm shift if the rest of the language was still imperative, it still would have been at least half of one. That affects how you design larger programs. In a lot of good ways, I think, but still, change with an unknown prospect of payoff.
So... it depends on your point of view. It's not revolutionary in the sense that there's anything new in it. But it is a somewhat revolutionary combination of concepts.
You're even free to join me in being a bit sad that fusing your concepts to an Algol-descended language is basically mandatory for success right now. But, one step at a time. We are slowly creeping away from it. As I've often observed, programming as a profession does not move anywhere near as quickly as some people think; there's a constant surface churn of technologies and languages, but deep paradigm shifts take decades.