On reflection I think the metaphor itself is a red herring; we're always using them because they serve a great purpose. Tell an aspiring developer they can use goroutines to build a decently concurrent app, without much fuss, and they'll be delighted because the language provides a metaphor for it (way beyond a simple abstraction); tell them they have to understand mutexes, locks, processes, forks, and you've lost them.

What I see is a tendency towards the metaphor because that abstraction itself poses a challenge on top of the original one and the original problem itself is less interesting than the linguistic magic layered on top of it. You can talk at length about how bad the dog > animal OOP example is but you won't have much to say about OOP without that.

It's basically bike-shedding.