I can understand this in in certain contexts, such as a site that exists solely to post public information of no value to an attacker.
A local volunteer group that posts their event schedule to the web were compelled to take on the burden of https just to keep their site from being labeled as a potential threat. They don't have an IT department. They aren't tech people. The change multiplied the hassles of maintaining their site. To them, it is all additional cost with no practical benefit over what they had before.
This is why more and more organizations get away with only having social media pages where they don't have to worry about security or other technical issues.
Unfortunately, placing the information on a social media page burdens the people seeking it with either submitting to the social media site's policies and practices, or else not having access to it. This is not a good substitute.
It also contributes to the centralization of the web, placing more information under the control of large gatekeepers, and as a side effect, giving those gatekeepers even more influence.
Most social media are free and easy to sign up for taking under a minute to do and have user bases that can be measured in the billions. Most people in the world are willing to follow the rules.
Most people don't use social media via the web. They use it via dedicated apps. I think it's natural that people who don't want to deal with the tech side of things will outsource it to someone else. The idea that everyone will host their own tech is unrealistic.
For now, in some jurisdictions, social media is "free" for your customers in the sense that it's supported by advertising.
It's not free for you of course because advertising isn't free and from their point of view what you'd be getting is free advertising so they want you to pay them to put it in front of your customers.
The work and technical expertise to setup let's encrypt is less than the work to register a domain, set up a web server, and configure DNS to point to it.
You seem to have missed what I wrote in the first place: They aren't tech people.
It is additional work, and requires additional knowledge.
It was also not available from most of the free web hosts that sites like these used before the https push. So investigating alternatives and migrating were required. In other words, still more work.
To be clear, Signal is not available from F-Droid. The above link is about a fourth party publishing a Signal build in an f-droid-compatible repository.
It's worth noting that some cross-platform toolkits are non-native in the strict sense, but mimic each platform's native controls.
This is harder to get right than one might think; small differences in text rendering look very much alien to me, and user input handling that isn't exactly the same as the platform's native conventions will make me stumble every time I perform common operations.
In my experience, Qt does an excellent job with this. It's not technically native (except on KDE and other Qt-based desktops), but it looks and feels right, or so close that I find it comfortable and well integrated with the rest of each platform I've tried. I haven't found any other cross-platform toolkit to match Qt in this area, so that's what I use for now.
Some day, I hope we'll see an alternative that accomplishes this at least as well as Qt, while being more flexible to license, easier to bind to other languages, and better at memory safety. (It's written in C++.) There seems to be renewed interest in GUI toolkit development lately, perhaps fueled by the excitement for newer languages like Zig and Rust, so perhaps I'll get my wish.
On the other hand, the developer convenience offered by Electron et al. comes by sacrificing runtime efficiency. It's astonishingly wasteful of resources, and that waste gets multiplied by every computer that runs the program, and every time it is run. The long-term costs saved by the developer are thereby amplified and pushed onto the users, in the form of shorter hardware upgrade cycles (and potentially increased electricity usage).
Just as a book will be read many more times than it is written, the burdens associated with a program's architecture will be borne many more times (collectively) by its users than by its developer. This is why I avoid web-based tech when building applications.
Relatedly, I'm glad to see that sustainable computing has begun showing up in global discourse.
A local volunteer group that posts their event schedule to the web were compelled to take on the burden of https just to keep their site from being labeled as a potential threat. They don't have an IT department. They aren't tech people. The change multiplied the hassles of maintaining their site. To them, it is all additional cost with no practical benefit over what they had before.
reply