What specifically can swap do that RAM can't?
Hibernation (or suspend to disk). Real hibernation powers off the system completely, so contents of RAM are lost, and you have to save the state to some persistent storage. AKA Swap. Unlike Windows with hiberfil.sys and pagefile.sys, Linux uses swap space for both over-committed memory and hibernation.
On the other hand, hibernation seems a bit finicky to get to work well on Linux. Whether you "can" actually hibernate is a different thing. ¯\_(ツ)_/¯
What can be done with swap which would not also be done by adding RAM?
This question could actually be reworded into What can be done with non-volatile RAM which would not also be done by adding more volatile RAM? . Just because you happen to dedicate a partition for paging(a dedicated way of interacting with volatile RAM), it does not change the fact it is still a part of a persistent secondary storage medium. Swap partition is also not mandatory for putting a system into hibernation, a "swap file" created on a preexisting partition can be used as well.
In the end, whether you are using a swap partition or a swap-file, what you will be storing are things to be written to or from RAM. If you were to pull the power cord from a system with an enabled swap partition, that swap partition would not get magically erased.
While this swap data would not be read in at your next boot (because the paging file would have entries corresponding to processes that are no longer running), and some distros might take deliberate steps to destroy it either during a proper shutdown or a proper reboot, if someone were to pull out a cord out of a system they would be able to examine that swap partition forensically.
As far as the case of embedded devices you mentioned, Flash, being a type of non-volatile RAM (NVRAM or EEPROM) storage, wears out because its ability to take I/O hits (Flash Cell Endurance represented in terms of number of program/erase cycles) pales in comparison to that of volatile RAM. You literally shave off a layer of oxide every time you perform a write to that location, and eventually there is simply no oxide left to allow for persistent storing of the charge and it literally leaks out before its subsequent reading.
On the other hand, volatile's RAM's survivability is virtually nonexistent (on the order of minutes in ideal experimental conditions) in comparison to flash, if or when you cut off its power source. In the case of volatile RAM there is nothing to stop the leakage of the charge and the corresponding state of the flip-flop (inputs, determining outputs, which then re-determine inputs), aka feedback-controlled latches.
32GB RAM and no swap vs. 16GB ram with 16GB swap.
Asked like that, swap mostly does save money, increasing performance per dollar ratio, maybe also per watt.
But swap still is more than "memory as slow as a disk". It is a temporary storage for memory pages, which can be directly (dirty as they are, no filesystem overhead) loaded into RAM when needed.
Of course a lot depends on the load (the kind of the load), and the idea of swapping can even backfire. That is why there is "swappiness" parameter, besides swapon / swapoff itself, and the discussion about the right size.
From wikipedia I got this statement about "swap" in linux (in "paging" article)
The Linux kernel supports a virtually unlimited number of swap backends (devices or files ...
If multiple swap backends are assigned the same priority, they are used in a round-robin fashion (which is somewhat similar to RAID 0 storage layouts),...
This shows that you can turn swapping into something that makes more sense on the hardware level: a dedicated "scratch drive" would give these swapped out pages a better home. Ideally, a scratch drive should be (very) small but fast and robust.
According to the "new" size rule (square root of Giga), your example should compare:
16 GB RAM + 0 GB Swap+1000 GB Disk
16 GB RAM + 4 GB Swap+ 996 GB Disk
Because what really does not make sense is:
16 GB RAM+0 GB Swap + 1000 GB Disk
12 GB RAM+4 GB Swap + 1000 GB Disk
That would be a swap partition on a tmpfs ("ramdisk") - maybe not even too harmful, but I see no benefit at all here. You can't even hibernate.
(see below for zram, and zswap, though, when you add compression to that)
To understand swap You have to consider the whole system and the average load. And because vm/mm (virtual memory management) is a complex system it is really hard to name a clear advantage. I like the idea of a "smooth" transistion into a overloaded system.
I have 8 GB RAM and no swap. But still I defend the concept, AFA I can understand :-)
I found this redhat citation in one of the OP links. The scenario is an ever increasing memory demand, on 2 GB RAM + 2 GB Swap, if I remember:
... In our case [just illustrated], quite a lot of swap is available, so the time of poor performance is long.
But the alternative is OOM even earlier!
The "time of poor performance" is long, yes, but performance only degrades proportionally to the load. I don't know the context, maybe they just want to warn against a too large swap partition. It sounds anti-swap, but on second look is not.
Then again, for the same reason, I have no swap. I want to know when me and my applications hit the ceiling, and then I will decide if I have to diminuish the load, buy more RAM or activate a partition for swap (I have one or two small partitions ready for that).
I looked up this zram, and then zswap thing: very interesting...:
In comparison, zswap acts as a RAM-based cache for swap devices. This provides zswap with an eviction mechanism for less used swapped pages, which zram lacks.
On the other hand, zram works without any swap device. It makes possible what I said makes no sense, but I did not take compression into account.
My point is this eviction mechanism inherent in "swap". This can be very useful under high load, whether you swap by swapping out or by compressing.