I use WordPress because I want to spend the time I have for this site writing and putting projects online. Building a blogging system would be an interesting project of its own.
I already have enough projects waiting for attention.
At work I have built BizTalk custom components, APIs and a management portal. I enjoy that kind of development. For a personal blog, I want the ordinary publishing tasks to be readily available: drafts, revisions, image uploads, links and a way to correct a post without redeploying an application.
What I would have to build myself
The first version of a home-built blog could be very small. A few Markdown files and a static-site generator might be enough for text. As soon as I wanted an editing interface, media handling, previews and access control, I would have more code and deployment behaviour to maintain. Each addition would take time away from the posts the platform was supposed to hold.
A static site would still be a sensible choice if I preferred editing everything in Git. For this site, the WordPress editor and media library suit how I publish. I can make a small correction through the browser and keep working on the article.
There is still maintenance
Using WordPress leaves me responsible for updates, account access, plugins and backups. The public articles do not contain much sensitive information, but the administration accounts and site configuration still matter. I would keep the plugin list short and remove software that no longer has a purpose.
What the backup needs
My recovery plan needs both the database and the files, including uploaded images and any theme changes. WordPress’s backup documentation explains the distinction. An export of posts is useful, but it is only part of restoring a whole installation. I would test a restore somewhere separate before relying on a backup.
For a theme or plugin change, I would check the homepage, an ordinary post, a post with media and the mobile navigation. Those are the paths visitors actually use here. A successful update notification says less about the site than opening those pages and trying them.
Keeping the choice proportionate
WordPress has an established ecosystem, and I can usually find documentation for a problem without implementing a feature from scratch. I also like Ghost. I have not made a detailed feature comparison that would justify dismissing it for other people; WordPress simply fits this blog and the setup I am willing to maintain.
I still appreciate very small tools. I reach for nano more often than Vim, and a heavy IDE can be frustrating when the task is a tiny edit. The same preference applies here: I want a publishing setup whose routine work stays small enough that I keep using it.
If writing becomes harder because of the platform, I can revisit the choice. For now, the useful next task is usually finishing a post, checking its links and making sure the pictures load.