As you grow older and have more experience as a developer, when you hear about silver bullets, you know that someone is trying to sell you snake oil. Software development is not much more than a series of compromises.
When I read about the comparisons between architectures and technologies, I look at the arguments being presented and the context. Often posts and "hot takes" have arguments, but most lack context. When a novice engineer reads that MVVM is the way to go, their belief in such a statement is proportional to the author's number of followers. The more street credit you have, the less scrutiny you get. As a reader, you are charmed into thinking that because MVVM worked for a random stranger, it will work for you as well.
Personal experiences shape the way we think and behave. If we had a bad experience with MVC, we assume that MVC is terrible. If you see a developer encouraging others using MVC, we think that the person is stupid. We evolve and hopefully become better by going through life's hardships. It's natural to wanting to avoid past bad experiences.
As mentioned, context is essential. And being mentored by someone that didn't know how to use MVC might make you think that the fault was with architecture and not with Chad. He was a pretty cool guy; and the codebase was already a mess when he joined, anyway.
When looking at a tool one should ask: is this the best option for my team and me? Technology is a significant factor. For instance, you wouldn't use a dependency that is poorly maintained. Likewise, you might avoid an architecture that is not well known in the community. Technology, nonetheless is not the whole picture, although less experienced developer will think so. The People factor can sometimes be more substantial. Does the team know how to use the technology? ReactiveSwift, and other FRP* libraries are canned because of this question. How long would a junior developer take to understand the codebase? Questions like these and others guide a team to a final decision.
At an extreme, even with the amount of flak that Viper gets, it can be the right solution if the team is delivering quality software on time.
Twitter, and more serious places are usually riddled with "use X because Y", or "Z is shit because I had a bad experience". Trimming away subjective experiences is mandatory when making an objective decision about how you are going to architect your next app, or introduce a new tool in your company.