Tldr: avoid rewriting software. Most likely the gigantic monolith got big because because of all the business logic encoded in there.
This is Cunningham's Law [1]! And it seems exceedingly plausible after observing behavior on many online forums!
I check with VSCode regularly because obviously an editor that is used by that many developers is worth keeping tabs on (pun n.i.).
I spend some time with it and then go back to Emacs because I can’t justify the trade-off, giving up the raw power and performance for just being more in sync with my team or something.
I’ll readily admit some of the extensions are very nice, like stuff for Kubernetes and so on, and they work well out of box. On the flip side, the customization story is not so great.
With Emacs, I usually spend a bit of time with a new package learning how it works and customizing it to my liking and then it typically becomes more powerful and integrated in my workflow than the VSCode equivalent. Plus the LoC count of a package is usually far far less than of an VSCode extension and I can audit it much faster.
Years ago I had an issue with VSCode: it was missing a small feature that was very important to me, with the GitHub issue stuck in limbo.
I ended up going into the source and implementing the feature myself. It took a few hours after bugfixing, I think the fix was ~100 LOC. Then I used the locally-built version. I recall building took a while, and the source and artifacts took a lot of space, but no other problems.
I also created a PR referencing the issue and it got merged rather quickly. Someone else ended up finishing the work since there were some problems (I think relating to coding conventions, and possible edge cases I didn’t need or handle).
Maybe I was lucky for the feature to not require much edits, and probably for the PR to get taken over and then merged fast. But it seems like the author's issues are also small, and it would be easier and more ergonomic to patch VSCode than to create an entirely new debugger.