That large companies also do this is another story entirely.
The GUI used wxWidgets using C++ and included a 3D section for system layout (using OpenGL). All of the 2D GUI controls for the rest of the system were "owner-drawn" which means that they overrode the ::OnPaint and drew themselves so as to look different than native controls (as audio systems always have to "look different").
This means buttons, toggle buttons, radio controls, control surfaces, sliders, meters, compressor meters, knobs, graphs, charts, lists, grids, EQ control graphs, everything. There were no native controls other than in popup dialogs (like saving/exporting). It redraw every 50ms based on data that it was receiving over the network from a series of hardware, with this data logged and processed in background threads. It used less than 1% CPU and a fraction of the RAM mentioned here for a chat app, even with cached in-memory bitmaps that it generated in code for drawing.
This ran on Mac OS, Windows and Linux. This means a native binary on each system. It can be done.
It is wrong to say that this embedded-web-app way is the "only way" of doing it. Not to be rude, but it just means that the devs can't be bothered to do it another way.
And that was me writing all of it, plus one guy who did the networking library. Two of us.
How can they "not have the resources"?
Web dev tends to optimize for ability to change/improve quickly (for good and bad). Resource use on the computer typically not prioritized.
For audio hardware, you don't want to be grabbing software + firmware updates multiple times a week. You might be on tour with the hardware and changing it whilst on the road is likely a no-no.
I am now at a place where we ship daily, sometimes multiple times (different branches). The emphasis on decent code and quality is now higher than the previous place I worked. The codebase here is also incredibly vast by comparison.
We can still add features quickly but it is of little use if it is of poor quality. What's the point of bad software even if it is quickly shipped?
I feel Signal should have implemted the core messaging components as a non-gui program or library or plugin to another Messaging app (e.g. Pidgin). Then if they want their own app, they could have used a lightweight cross platform window toolkit (e.g. WxWidgets or Qt).
I've got a lot of tabs open right now and I'm not sure how to read the memory usage in Chrome's task manager, but Chrome appears to claim to be using about 450MB just for the browser, plus some additional amount for each tab I have open.