First of all, this is an answer to the original post, I skimmed through the other answers, but I don't want to take part in that mud fight, but if there already where some answers to what I am going to write, I might have missed them.
One thing before I start, I don't think that this phenomenon is so new. Big electron desktop apps like VSCode exist for like 6 now.
So let's first consider the web technology itself. As many languages have a webasm or javascript transpiler, this is completely independent of language.
The first point is of course the most important one, cross compatibility. Your code needs to be developed for a browser, not a platform. No matter if it is running on an android smartphone, a Samsung SmartTV or a Windows Desktop, it will always work the same. This is something you can not say about native solutions like Lazarus. If you consider developing an app that should work on iPads, PCs, Macs and Mobile, web technology is a great choice.
If I for example would write a chat application, I would definetly use web technology because if a chat does not work on mobile it is basically useless in a Smartphone world. And just between Android and iOS are so many differences when developing native that mobile alone is a reason to use webdev.
Then you can also provide portability through the browser itself. Apps like slack are basically just a bottled up version of the browser code, with a few extensions to make use of the native API (like notifications). But in general, if you want to provide a service via browser and natively, like many chat services such as slack, using web technology halfs the amount of work you have to do.
A big point is also the graphic features of the Browser. Browsers are optimized for very fast rendering of complex graphics. From the HTML DOM styled with CSS to the "handrawn" functionality of the Canvas using Javascript, the browser is really really fast. Things for which with Lazarus you would need to fall back onto using OpenGL or something comparable.
Many applications using web technology have a custom design. Slack, Riot or VSCode make no use of any "standard" components like the default system style buttons, but are completely customized. And users like pretty applications. Every time I see Java users switch from IntelliJ to Eclipse, you can see how much they dislike the Eclipse design, even though it is much more classical then the fully customized IntelliJ. It has a reason why Microsoft has introduced WPF to .Net. Maybe it is just a trend (I remember back to like Windows 2000-xp times there was also a trend to custom designed applications that died out a few year later when Win 7 rolled around), but at least right now, it seems to be something users like if an app has a unique style, as long as it is pretty and well structured.
Not only graphics, but more generally speaking browsers heaviely support Multimedia functionality. To implement a cross platform video player in a native GUI app is pretty complicated and often requires additional dependencies like VLC or so.
Then there is of course the tooling and support. It is vast, well tested and most importantly free. There are other frameworks that try to replicate these advantages for other platforms like Xamarin for C# with .Net core or Firemonkey for Delphi, but here you are paying for things that are free with web technology and have a bigger community, better support, more libraries than these payed alternatives
Also it is just very easy. Native system APIs like the Windows API are, due to having to be very generally applicable, very complicated. Web APIs are usually much more straight forward. I had to go and read something up in the POSIX standard more than once to build a native Linux app, I never had to read any standard for web stuff like IndexedDB or something similar.
Lastly, web platforms are designed for event based development, which perfectly aligns with how GUIs operate. Most APIs in the web are designed around asynchronous single threaded callbacks. This avoids mangling with multi threading problems, deadlocks and so on, while still allowing for a fluent GUI design.
There are the buildingblocks for this available in most other platforms, for example Lazarus GUIs use the Synchronize function to schedule function calls within the event queue of the main thread. This is used by some libraries (I think indy uses this method to schedule event calls), but this is just a "patch" to make an inherently synchronous system asynchronous, and only works if it is specifically implemented. All the system apis, etc. are inherently synchronous.
The in browser on the other hand everything revolves around the asynchronous event queue. All APIs are designed to make use of that, which matches very well with the way GUI applications operate. This btw also to a very frustrating degree (e.g. you have old style callback functions mixed up with new style promises, which can be really confusing) but from a design perspective for GUI apps its fantastic.
This is where you can't spearate that well anymore between the platform and the language design, because the browser is made for Javascript and Javascript is made for the browser. And while there are a lot of issues with JavaScript (as it is grown historically it has some really annoying things about it, e.g. iterating through an array via for ... of because for ... in was already taken), it clearly shows that this language was designed for event based GUI development, especially with the DOM.
For example the event based structure of the APIs synergises really well with Javascripts heavy reliance on lambda functions, a feature that came really late to many other languages.
And of course not to forget, to start developing with Javascript, all you need is a browser and a text editor. No toolchain is needed, which is why prototyping in Javascript works really well.
So to summarize, why to use Javascript for desktop apps?
- Cross compatibility to all platforms
- Great for complex graphical interfaces
- Publishability through websites allows for inherent portability
- Large community, many libraries and a lot of support
- Inherently designed for GUI development
- Easy
A development environment is only as good as it fits the use case. Let me give you two examples, one where webtechnology is very useful and one where it isn't.
Let's say you want to build a chat, that should run on all platforms as app, be accessible via a website if you can't install the app, e.g. to check in from a foreign pc, and this chat requires a lot of multimedia functionality, like playing voice messages, or viewing videos sent via the chat. I would definitely choose web technology, no questions asked.
If I had a program that needed to load and parse binary data, e.g. file compression or something similar, which probably can be parallelized in multiple threads and is very IO heavy then I would defenetly not use web technology.