Does a single replica gives any performance improvement? Consider a case where you have a single PostgreSQL database. Then you add a replica (hot standby) and you send all the reads to that replica. This is what does Rails for example.
Does this gives any performance benefit? For my understanding the answer is no.
Let me explain:

when you have only a single database it gets N writes and M reads
when you add the replica, the replica has to perform N writes (replicate them) and M reads... so there isn't any advantage.

Basically adding replicas does not add any benefit for writes (i.e. 2 x number of machines =&gt; 2 x number of writes).
The only advantage would be to split the reads: but in that case you need to split the reads between the master and the replica (or between multiple replicas), otherwise it is useless. So the strategy adopted by Rails (i.e. moving all reads to the single replica) seems not effective to me.
Am I missing something? Is the write work performed by a replica less then the work of the master (considering that each update must be applied to both the machines)?
Am I missing something? Is the write work performed by a replica less then the work of the master (considering that each update must be applied to both the machines)?

Probably yes, you are missing something, and write work done on the replica is less than the (total) work of the master.  It is rare for every write on a database to be of the form update foo set bar=592 where pk=127.  What if it were instead update foo set bar=592 where bar is distinct from 592 and pk in (select foo_id from baz where t ilike '%one fish%' and sin(foo.z)&lt;sqrt(baz.y)/7) and tzr @&gt; :something.  How many reads (and CPU time, and memory) would need to happen to figure out which writes end up happening?  Replication, however, just needs to replay the end result.
But if you were setting up read replication just for performance, it would be pretty weird to set up just one of them.  Unless that one was on your LAN, while the master was someplace with more latency.