I agree with your more nuanced take on the golang community's position. I still think that a fully realized framework is, in general, a better starting point for the vast majority of projects. Part of the problem is that such frameworks are few and far between. I'll stick to the Ruby community: I know developers I respect who really like Sinatra, which would be more akin to a microframework. It is their go to starting point, but when I go to work on their projects I very quickly find myself straying out of Sinatra's capabilities into things that are fully baked into Rails. I then have to spend time pulling that capability into Sinatra, which is not how I like to spend my time as an application developer. There are many frameworks that are positioned as 'elegant' or 'focused' when they are simply incomplete in the face of real world development and teams end up having to either cobble together disparate micro-framework or rebuild basic capabilities to get to a fully realized app. I would argue that is not time well spent and that everyone thinks they are super good at creating solid, performant, extensible, well documented code, but they are not (statistically speaking) and by then it is too late and others have to live with their junk for years, or worse yet they all bail because now they know hot-framework-x and board the recruiter train to their next salary bump.
