All of this is true. And it's also why inevitably all my more complicated emacs configurations inevitably end up broken in some way over time :-)
What you get in return though is far more valuable than any alternative — when something breaks, YOU can fix it. You're not waiting for a vendor or update. The system is transparent and malleable. Each fix teaches you something. Over time, you build deep understanding of your environment. The chores become easier. Unlike rigid software, Emacs molds to your exact workflow. The maintenance cost pays for a tool that works EXACTLY how you think.
Emacs is a professional chef's kitchen - A chef maintains their knives, adjusts recipes, deals with temperamental ovens. More work than a microwave dinner, but they can create ANYTHING. When the soufflé fails, they know why and can fix it.
"Yeah, well", some may say, "I don't want to be a chef, I just want to occasionally fix some bad cookies, using the 'easy-cookie-maker-kit', it just-works™, why not use it?".
I can tell you my perspective on that. I decided to "become a chef" and use "my own kitchen", because I'm tired of different types of cookie-maker-kits. It seems like everyone has a different opinion of what the cookie-maker-kit should look like, what it should do, what kind of cookies can you make with it. Every few years, the "ultimate" kit appears, promises to revolutionize cookie-making, then gets abandoned or dramatically changed. Your muscle memory becomes worthless. Your recipes need rewriting. The new kit can't make the cookies you loved.
But in my kitchen? My grandmother's rolling pin still works. The oven I learned five years ago still bakes the same way. When I discover a new technique, I add it to MY repertoire, not wait for someone to maybe include it in Cookie-Maker-Kit 3.0. Sure, I burned a few batches learning temperature control. Yes, I maintain my tools. But now I can make cookies, and bread, and soufflés, and things that don't even have names yet.
The cookie-kit users are still arguing about whether round or square cookies are "correct," while I'm over here making star-shaped ones because I felt like it today.
But also I have absolutely zero desire to run with modal keybindings, which seems to be Doom's schtick.
Doom may become obsolete only if it keeps partitioning into separate packages, e.g., doom-modeline started as a core component of Doom, now it's a separate package. Similarly, nothing really preventing anyone from forking other core parts of Doom into separate packages.
Also, evil-mode keys are optional, anyone can use Doom without using vim keys, there's still good value in doing that.
Very subjective. I understand the rite-of-passage impulse to build one's own config. But it is simply too much time/effort investment if you are relatively new. This I say as someone who had my own config for a couple of decades.
When I came across Doom, I threw mine away and just adopted it. I even learned to like VIM/VI style text editing to use Doom effectively.
I also like the GodMode/Leader/Model style of text editing. The keybindings are more intuitive and more discoverable. When I enter a key and wait a bit, doom pops up next available options. I no longer memorize the keybindings. Just use the whichkey integration to find things I use infrequently.
Not to mention that it is well tested with the sets of packages for each release.
Obviously, not for everyone.
But I am a happy user and hope it exists for a long while.
I sure do get the appeal of an out-of-the-box Emacs setup that does everything with modern defaults, but the base installation gets better, more ergonomic, and more powerful by the year on its own.
I have learned tons of things since then and on multiple occasions I thought about rebuilding things (with my now more extended knowledge) from scratch, but I'm afraid I will inevitably end up borrowing some core Doom macros, and end up recreating something that very much looks and feels like Doom, without being Doom, perhaps with a different package manager. That I believe is the only non-negotiable part of it today. Other than that, Doom is nothing but a very thin layer of abstraction. I don't even use Doom's own modules, instead I built the set of my own. Anyway, if you ever feel overwhelmed and decide to call another emacs.d bankruptcy, maybe give Doom a try. You can disable all the modules and build on top of that lean core, it still has objectively nice features - CLI tool is nice, macros like map! and add-hook! and defadvice! are very cool. It loads extremely fast, etc.