The question is not elisp v. vimscript but rather the power of not having to switch contexts. To write code for a locally-hosted RESTful API I used Chrome to read the API docs, Postman to make the calls, iTerm2 to start/restart the server and read the logs, and a text editor to make changes. I replaced that flow with eww, restclient.el (amazing!), multiterm, and an editor buffer. No changing of context, conserve about ~1GB RAM in Chrome instances, full-screen if I want it, and everything is text (I'm looking at you, Postman).

On the "highly custom" level, I have a work-in-progress script that takes a URL, sends it to a Splash server, and returns the rendered HTML to eww for viewing. This is great for annoying SPAs like the article that spawned this conversation.

My current goal is to swap out my development MBP with an eInk tablet and bluetooth keyboard. Success will be measured as a function of productivity and weather-/water-/environment-proofing of the device; the goal is productivity in full sunlight and/or under water. Emacs will have a central role in that. Just need to find an eInk device with adequate screen refresh rate and Bluetooth support....

Not downplaying your choices but throwing this out there. Vim can and does all of that as well.

vim $DOCUMENTATION_URL (curls the page and opens in vim)

vim-rest-console

:terminal (new!..ish. Works great.)

I'm using Org Mode to write my thesis and, although most of the functionality I use comes from vanilla org mode, I do need to write some Elisp to get the LaTeX export working properly, and to knit different projects together into a single one. As another example, it took me less than 30 lines of Elisp to get Apple Music incremental searching from within Emacs. A highly custom thing that I don't get elsewhere.

I think you've assumed the wrong premise. At least for me. It's not the highly customised things, it's the accumulation of the small things that are either missing, inconvenient, slightly annoying or somewhat different to your needs.

Every package developer makes choices about how their package works (and built-in behaviour too), but sometimes that clashes with what you want, or is somehow inadequate.

It's those small conveniences that have a disproportionate impact.

I'm not saying you can't do similar in vim or there aren't other ways to achieve the same goal, I'm saying that over time, those minor improvements have a huge impact.

Here's 2 examples:

1) Splitting a window horizontally by default splits 50:50 but on a 16:9 monitor I usually want the new buffer (right) to be smaller than my current buffer (left). So I override the defaults.

2) I use paredit for lisp based languages, but (as far as I'm aware) there's no built in-command to copy (or paste) the s-expression surrounding the cursor's current position.

I often find myself wanting to do exactly that e.g. in a let or a cond form in Racket. So I wrote a couple of small functions to do just that, bound them to keyboard shortcuts and I've now made a minor extension that fits exactly what I want to do. Since lisp is based on s-expressions it turns out this extension to someone else's package is incredibly versatile and useful.... TO ME!

    (let [<CURSOR>(x (some-function with args)] 

I press my chosen key-combination and it becomes

    (let [(x (some-function with args)] 
         [<CURSOR>(x (some-function with args)] 

ready to edit the new s-expression

In vim, when you're in visual selection mode, you can type `ib` (inner block) to select the innermost parenthesized block's interior or `ab` to include the parentheses. If you type these commands multiple times, the selection widens to the next, next, next ... enclosure.

There are other similar commands in the category, like a" for selecting the interior of a double-quoted literal and such.

They are documented under ":help visual-operators".

I occasionally use elisp while replacing with regex(you can do computation on captured strings), can you do this in vim?

Yes, select in visual mode type :! and it gets processed by a unix command.