Didn't read the article, but from the snippet you've posted, it's simply incorrect.

Assumeutxo is neither a new type of node, nor a pruning. It's about making the software usable without having to wait multiple days for it to sync. It doesn't reduce the hardware requirements to run, in fact, using assumeutxo probably requires more resources than without it.

Assumeutxo allows a node to start with a preset UTXO set (provided by the user, and does not necessarily correspond to a hardcoded hash in the binary, this detail has not been worked out yet). This UTXO set is the state of the chain at a particular block hash and height. The node can then begin syncing from that particular block. The idea is that the block will be recent, so the node will be caught up to tip very quickly, thus allowing the user to make and receive transactions way faster than if they had to wait for the entire blockchain to sync.

The point is to make the software usable much faster. A major complaint that we've heard from users is that it takes ages to sync. Users often don't have the patience to wait and will start giving out addresses. Then they panic when they don't see incoming coins because they haven't synced yet and they come into this forum, or github, or reddit freaking out about losing money, all just because they haven't waited for the node to sync. Assumeutxo reduces that because it "syncs" faster.

Obviously there's a trust requirement in this - users have to trust that the UTXO set that they are using is correct. Assumeutxo mitigates this by actually syncing the full blockchain in the background. While the user is using the state provided by the UTXO set and the chain state extended from it, a second chain state is built in the background from syncing and validating the blockchain. Once that background validation reaches the preset UTXO set's height, it checks that the two states are the same (same UTXOs, same blocks), and will kill the software and give the user an error if they are not.

This is, in fact, not pruning, and unrelated to pruning. Of course, it should be possible to do it with pruning, but I don't know if that's been implemented yet. Furthermore, two chain states are being maintained in memory and on disk while the background validation is going. This means that the resource usage is actually higher, not lower.