The best way to approach things is incrementally. Find some pain point in your current workflow and write a little bit of Elisp to automate the painful bits. Let's say you're running manual UI tests and then eyeball-grepping the logs in your backend. "But nobody does that!" you say. "Why would anybody do that?" Heh. You'd be surprised. Anyhoo, thr crank has to be turned on a prod deploy by COB Friday and you've got no time to investigate Nightwatch or the other UI-testing libraries out there, let alone integrate them with a log watcher.
Thankfully you're an Emacs user! So you write a little Elisp to start the back end, capture its output in a buffer, and count the number of occurrences of the log cookie that represents a successful (or failed) row insert, etc. You haven't automated your whole process, but you've automated part of it, and that's saved you considerable pain. And it took maybe half a page of Lisp, if that.
Recently I was confronted with an ancient web service whose only integration test process was "manually hit the endpoints with Postman, then check to make sure the records hit the database". So I wrote Emacs Lisp code to send the requests, run the queries, and even manage the Docker container where the service lived. This let me run the whole process much faster with a few M-x commands. It was nothing fancy, either, I just wrote code to spin up curl, Docker, and SQL*Plus and capture and examine their output, sort of using Emacs as a powerful full-screen shell. Rather than get in my way, it became a versatile tool I could apply to the task to get things done much faster.
Again, this is the difference between an extensible editor and a completely malleable one. VSCode, JetBrains, or Eclipse cannot be extended as incrementally and on-the-fly as Emacs.
A few times a month, I'll do more extensive work, focusing on a number of long-term projects or exploring various ideas I've had and put down in my notes. All this work is geared around helping me manage information more effectively. I'm an information junkie, hopelessly addicted to the Internet and that's by choice. I wouldn't give it up for nothing.
Emacs is the tool that makes the difference since this continuous feedback loop of me adapting Emacs to help me deal with more and more information, allows me to keep up. Being an information consumer is easy today, you simply sit back and absorb what's being blasted at you. Being plugged into numerous signal sources and managing that information _on your own terms_ is the tricky bit and where Emacs shines while most other tools fall flat, since they're either too constrained or lack the necessary programmability.
The problem is that these days, you could use vscode or atom for a month or two, and get that same feeling. Emacs from scratch is not a great use of time anymore.
Emacs is simply something else.
And I'm not sure the ceiling is actually lower.
Writing code, reading/sending email across ~30 email accounts spread out over different services, reading newsgroups, mailing lists and RSS feeds, maintaining a presence in 7 different IRC servers with ~30 channels total, using a variety of connection methods, watching and filtering certain twitter feeds, controlling external applications through Apple Events [1], file management local and remote, remote system management, local virtual machine management, note taking, calendar, agenda, notifications, bookmarks for external applications (Chrome and Preview), password manager, version control, music playing.
I can keep going. The only programs besides the OS and Emacs I use on a regular basis are Google Chrome, Preview.app, VMWare, Calibre, mpv, bash/ssh, Unix command line tools (less and less) and my bittorrent client written in Common Lisp.
I've almost finished an Emacs Lisp controller for Chrome, allowing me to bring a lot of information (e.g. tabs) into Emacs in order to rapidly manage it on my terms. I've done the same for Preview.app. I treat it as a dumb vessel that does the rendering. The actual information (filename, metadata, current page, date etc) is extracted from it, stored and manipulated in Emacs. That way I don't rely on Apple to dictate how I'm allowed to use my computer. I can experiment with different paradigms and find the one that fits me best. Emacs is the magic that makes all of that happen.
Extensibility was emacs' killer feature when its main competition was vim and vimscript - that's just not the situation anymore.
I didn't write all of the Emacs Lisp programs I mentioned, but I did go through most of them, changing the way they work to fit how I wanted to use them. This was an iterative process that is still ongoing.
What should impress you is not the breadth, but the paradigm itself as expressed in Lisp. You can probably write an IRC client in JavaScript and have it in VSCode. But that's not what I'm talking about. We're not ticking boxes down a feature list here to say "JavaScript can do that!". We're talking about a paradigm, and specifically about interactive development with a short feedback loop through Lisp which is "a difference that makes a difference" [2]. But in order to truly understand this, you have to go through the process. Philosophical truths can not be transmitted like pieces of eight.
[1] https://www.dreamsongs.com/WorseIsBetter.html
[2] http://www.informationphilosopher.com/solutions/scientists/b...
Atom is much better, and feels closer to Emacs in terms of allowing you to extend and modify almost every part of it.
That said, Emacs is just the king. Not only can you really just change absolutely everything, it is really easy to modify it all at run-time on the fly, which even in Atoms isn't quite so.
I had settled on Atom for a while, but the slow performance and high memory use made me switch to Emacs.
Deep diving into emacs is not a productivity booster - its a hobby that one does for its own sake, if that's the kind of thing that floats your boat.