UVM - is it necessary to divide monitor into proxy monitor class and a BFM class

The latest cookbook show monitor being broken into a class derived from uvm_monitor and then an interface class.
The proxy class, as expected, delegates bus function to the interface class.

My question is, is there any advantage of this approach compared to traditional approach where monitor class handles everything related to bus function itself?

We updated the Cookbook to encourage this new “split transactor” approach to facilitate the eventual migration to emulation, where this split is required to maximize performance. It is consistent with the UVM Framework and with Questa VIP components as well.

In reply to tfitz:

Another advantage of this approach is a clean separation of timing abstractions. This keeps all of the physical clocks in RTL, and your UVM testbench becomes pure transactional.