The buffer pool also benefits writing changes. When you change a row, it is first changed in the copy of the row's page, which resides in the buffer pool. InnoDB flushes that page back to disk later, and doesn't make you wait for the flush to finish before it calls the update complete (it only has to log the change in the InnoDB redo log to say it's safe).
The buffer pool also contains the change buffer for secondary indexes. This basically queues up updates to indexes, so when you update a table that has indexes, you don't have to wait for your updated values to be inserted into the indexes. This will also happen later in the background.
So both reads and writes benefit from having a buffer pool, and also both source and replica benefit from having a buffer pool. The larger the buffer pool, the more likely a given page may already be in RAM when you run a query either to read or write that page.
There is a point of diminishing returns on increasing the buffer pool size. If you only have a small database, say 10MB, it makes little sense to allocate many gigabytes of buffer pool.
But it's common to have a database that is larger than your RAM, so then we expect the buffer pool to be sized to hold the most frequently-accessed subset of database pages. Not all of your database is equally likely to be queried. Therefore it could be that a buffer pool 1/4 the size of your database is sufficient to make 95% of your queries run without needing to load more pages from disk. These ratios are just an example, because it depends completely on your application.
