You have Galera active, but are using it as a "single-Primary" with "multiple Replicas", correct?
All writes occur on all servers. This is a fact of any replication topology. There is some optimization of a "write" as it moves from the Primary to the Replica, but this does not necessarily allow the Replicas to be less "solid" than the Primary.
As for your quote -- that applies to standard replication that comes with MySQL/MariaDB. When adding in Galera, the "gcache" is used instead of the "binlog".
Somewhere else the documentation recommends that the Replicas be as powerful as the Primary. But that assumes you are also using the Replicas as read-only workhorses, which does not seem to be your case.
Here's a guess at what you are experiencing. You have some particular type of complex write-query that costs just as much to perform on the Replica as on the Primary, and/or you have less RAM or HDD instead of SDD on the Replicas. A possible example: an
UPDATE that modifies most of the rows of a million-row table.
It may be possible to keep the same hardware but "fix" that query. But first, you need to identify it; then we can see if there is a way to rephrase it or add some composite index. Turn on the slowlog and have
long_query_time=1 on all servers. After a while, use
pt_query_digest to locate the "worst" queries. Then start a new Question to discuss speeding it up in a Galera environment. More: SlowLog
As I understand your picture, you have a 3-node Galera setup with one of the nodes having an asynchronous (ond fashioned) replication leading to a Replica. The main factor in whether that Replica is "up to date" is whether the binlog from the cluster node is being sent promptly to the Replica.
Even if the Replica is less powerful, it will eventually catch up. (Unless it is much too weak.)
Seconds_behind_master indicates the delay in applying the
UPDATEs (etc). As long as the node that is feeding this replica as sent the updates, the Replica can eventually catch up.
If you have all 3 cluster nodes in the same rack, or even in the same data center, then you have a "single point of failure", namely the rack or cluster. Is that your topology?