Not even close. Obvious from the fact that about >90% of text editors out there have visible _lag_ when inputting or modifying text. Visible _LAG_. (see emacs, nvim in certain configurations, vscode, sublime, etc)
A text editor should be running at DRAM read/write speeds nowadays (amortized), which effectively means that any form of edits you do should be imperceptible to you.
It only means that >90% of text editors use the wrong UI toolkit for the job. We already had faster editors on the Amiga 500 (CygnusEd) than we have now. The fact that we don't have them now is that we regressed. We had it, and we lost it. It's an entirely different matter from not knowing how to do it!
Emacs does start fairly slowly, though, takes about 0.6 seconds.
1. Don't load too much at startup, use use-package's :defer keyword where ever it makes sense.
2. Set gc-cons-threshold to a very large value during initialisation and turn it back down again once everything's loaded. That said, most-positive-fixnum is probably overkill and I should look for a way to reliably set it to half of my PC's RAM.
A less important third way to reduce startup times would be to byte compile everything (possibly even the early-init.el, init.el, and custom.el files, although that does mean you need to recompile whenever you change anything), but that doesn't gain you much.