Why Wordpress?

Another not-WordPress alternative is a software called NibbleBlog [0] which is nice because it's also written in PHP and will likely be easy for existing wordpress admins to deploy. No change in tooling. This also doesn't require a DB, it can run from flatfiles.

[0] - http://www.nibbleblog.com/

It's the first choice among a huge number of web devs though, which seems contrary to it being that the person deploying it doesn't know better.

WP felt like a good default 'go to' choice 10 years ago. Certainly, in the last 5, it does not feel that way to me, even though I still do use it for some projects (myself and my clients) but it's not a default, nor is it by any means the only tech stack I work in (There are a few things which don't get called out very much, but which were/are some of the underlying motivating factors for people defaulting to wordpress (perhaps as a more root underlying reason behind some of the 'large ecosystem' reasons people typically default to).

A primary one which gets overlooked is that fact that WP is about the only 'framework' of any sorts in any tech stack which allows people to simply move files up to a server. There are no command line incantations to run, no npm/build stuff to use, no compiling, etc. It's about the only platform I can point someone to where they can do an install themselves, and still make modifications later (days/months/years later). Many do 'one click' installs via cpanel or whatever, but even outside of that, the process to install and make changes later is about as basic as you can get - editing and moving files - nothing else needed.

Secondly, in the realm of web frameworks (whether we describe it as one or not, wordpress is indeed a framework, albeit possibly reluctantly for a while), it's one of the few that comes with a username/password/registration process ready to use, out of the box. Anyone looking to build any extension/plugin can count on a standard user/pass/registration/recovery process being there. Most other web platforms shun this most basic aspect, comparing their routing options and ms-oriented benchmarks. I think ASP.NET MVC v4 came bundled with a standard user/reg system?, and one might throw Drupal/Joomla in that camp too. Outside of that - certainly all the major PHP platforms for years - symfony, zend, kohana, code igniter, ez, etc - all gave you parts, then told you to build it youself. Typical rationale was "everyone's needs are different".

So... people 'build it themselves', thinking their own needs were 'different' from everyone else's (hint - vast majority of times, they're not), then we wonder why things get hacked, and point the finger at the devs themselves who... shouldn't have to be reinventing that wheel every other month. Devise in Rails seemed to have been a go-to for a while, and many other languages tend to coalesce around 1-2 frameworks and 1-2 user/auth libraries, but the PHP world is just too damn big for much consensus...

Except in Wordpress. Whether it's good or not, it provided enough of the basics in a standard way to become the basis for people to build on. And... build they did - often extremely poorly (no, really, not everything should necessarily go in to 'wp_options' - session data? really? and I have to run my own stuff to clean it up?)

These low barrier to entries have been at the root of why WP has gained so much popularity and control.

I certainly know there are 'good' ways to develop with WP as a basis, if you wanted to. And some people really want to. But doing things too 'correctly' from a dev standpoint (migrations, testing, dev/staging/prod setups, etc) means you're now fighting against the WP core principles of 'move files up and execute'. The core of WP doesn't support these concepts, and tacking them on feels... tacked on. You're also alienating yourself from the 99% of wordpress developers (in every sense of that word) who do not even understand those concepts in the first place - they will never be able to use or contribute to your code/project/tool. At some point, doing things the 'developer' way conflicts so much with the core ethos of WP, that you're fighting the base, and there's probably not much benefit (outside of latching on to the name recognition) and you're probably better off in another tech stack.

WP itself providing some 'blessed' approaches for creating plugins with testing processes, standard/defined way of importing/exporting plugin data, and other attendant issues around plugins would solve problems for larger-scale developers/users, but might very well alienate many of the folks who were earlier adopters. But... at this point, where else would those folks go?

I love wordpress, but I don't love PHP, updates, security flaws, or hosting. I haven't done it yet, but I'm considering using the Simply Static plugin[0] to migrate to generated static pages from my wordpress instance, which sidesteps all of those problems.

[0]: https://wordpress.org/plugins/simply-static/

Another great motivator is that $30 or $100 is utterly trivial in the context of any website that has some actual business value and investment in its content and design. I know we're all conditioned to think web services should be nearly costless but I happily pay my WPengine bill for multiple sites every month and consider them keeping an eye on things a very good value for my fairly nominal expenditure.