I would happily take that bet, because you’d lose!
Currently, those same sites run 47 plugins. But that doesn’t mean that I have cut stuff out. Quite the contrary!
I learned how to code by working with those plugins. After a while, I found that I wanted to tweak many of them to do something specific that the original code wouldn’t do. So I wrote my own code instead to replace those plugins. In some cases, I created my own plugin; in others, I inserted the code as single files in the
mu-plugins folder; and sometimes I added code to the theme’s
functions.php file. So it looks like the number of plugins has gone down.
But that exemplifies my point about the number of plugins being irrelevant. Although the number of plugins has apparently dropped, the functionality deployed on these sites has actually gone up. I could literally break out all the functionality into well over a hundred plugins if I so chose!
How would you ever be able to check the quality of the code of 80+ plugins?
And what’s wrong with simplicity?
Nothing, so long as it suits the purpose of the site. But everything, if the site doesn’t then accomplish what is required.
In any event, I am not sure that you have entirely understood my point above about plugins doing different things. Not every plugin is about what happens on the front-end. So, for example, I have a plugin that logs activity on the site and any changes made; another that logs all emails; another that logs all REST API activity, etc. If you want to debug something (whether in order to respond to a support ticket or when testing new functionality) it is essential to have proper records.
In fact, I have one site that has just 18 plugins active, and only one of them does anything on the front-end.
Oh, and if you’re thinking any of these sites will be slow, you’d be wrong. Pingdom measures all these sites as loading in less than a second. And, unlike so many membership sites, they don’t get any slower for logged-in users.