What could be the problem

[LoyceV]

I want to ask if that also applies to a prone node

Yes. A pruned node writes the same amount of data and uses the same amount of RAM.

[nc50lc]

-snip-

I think I understand your point but I want to ask if that also applies to a pruned node

Yes, and not only the advantage of higher dbcache, the available disk space of storing the complete UTXO-set is also required.
This is why even if you set the lowest possible prune setting, your node will still require about 13GiB of free space, mostly for the UTXO-set which may go higher or lower ("chainstate" directory).

As for major contributor to disk I/O, even if the node is in prune mode, it will also write all of the blocks to the disk as it downloads them from its peers, it will not skip a block.
The only difference is it will eventually delete the oldest verified blocks when it's near the set prune size.
So, that time-consuming disk writes and verification are also applicable to it, so as the config optimizations.

[LoyceV]

As for major contributor to disk I/O, even if the node is in prune mode, it will also write all of the blocks to the disk as it downloads them from its peers, it will not skip a block.
The only difference is it will eventually delete the oldest verified blocks when it's near the set prune size.
So, that time-consuming disk writes and verification are also applicable to it, so as the config optimizations.

I'd like to add a side note to this: with low RAM, writing blocks is insignificant compared to writing chainstate. After the IBD, it adds only 10 MB per hour. And that's why Bitcoin Core works totally fine with the blocks directory on a slow HDD.