This response is not specific to WordPress, but applies equally to all web applications
The common benefits to offloading the database (or any component) is that you can manage scale, redundancy and security of that resource independently of the other resources.
In most implementations we are not offloading the database, but instead we are offloading the web or application host. This is because it is traditionally harder to manage horizontal scaling and synchronizing the data between a cluster of database servers, so we scale database servers vertically first (increase resources) but web applications and web hosting infrastructure is designed to support horizontal / scale-out first and is generally more economical to do so.
Many enterprise RDBMS engines achieve optimization through aggressively pre-allocating or reserving memory, this will reduce the memory available to the web hosting infrastructure. Single instance databases can usually handle a significantly higher magnitude of users than a single instance web front-end (WFE). At the point where you run out of resources if you only scale up (by increasing resources) you may find that the database engine is underutilized (due to the pre-allocation) and at a point you stop noticing improvements in the WFE performance. At that point you have no other choice than to scale out horizontally.
There is often licensing concerns around scale-out, many enterprise database licenses are charged per CPU, sometimes per core. It can be cost prohibitive simply on a license basis only, disregarding setup and maintenance costs to increase the database instance or core count if it is being under utilized.
The licensing argument goes the other way too, if your workload is quite small, then you can reduce costs by offloading your database to an existing database server or at least by pooling multiple databases on the same server.
There is also the security factor, we gain an extra level of security by not hosting the database server on the edge of the firewall with the Web Front End, but instead the database server should be fully protected within the firewall.
Although it is possible to run all processes on the same server, there is considerable RISK in doing so, I would not recommend single server deployments unless it was for non-critical, internal usage scenarios that have a low number of active concurrent users.
Same server deployments are harder to reinstall/configure after failure, you can restore the entire server image (if you have one) or you can try to reinstall and configure manually, however this can be a tedious process and may require a lot of individual components to be fine-tuned.
As your user base grows, at some point you will need to scale, you may not need to make that decision now, but the time will hopefully come. If you separate your Database and WFE components earlier in your project it will mean you are more cloud ready and in a position to individually troubleshoot or improve performance of the specific processes that need it when it is needed with little or no effect on the rest of the system.
In the modern cloud first era, a single all-in-one combined server deployment is reserved for early stage POC implementations. I can't think of any commercial scenario to host the database and web host on the same server instance. The risk that your entire database is compromised or corrupted is simply too high, given that for the WFE to work you must expose it to the world, but you do not want your database available to everyone, this could easily lead to regulatory compliance issues.
If your workload is not of commercial scale or you are utilising resources that do not actually cost you anything, not time or money, then perhaps you don't need to change and a single combined server can work for you, OP asked what the benefits are, asking insight into why you would do this at all.
In terms of disadvantages, the cost structure is obviously a bit more complicated if there are multiple resources that you must pay for, but that is really it. In general it is cheaper in terms of raw cost and time to maintain WFE independently of a database server, having the two workloads tightly coupled on same server introduces a lot of OS level dependency issues that get harder to manage over time. The point of splitting the resources so that they can be independently deployed is that it gives you the freedom to manage those resources to find a balance between performance and cost. If hosting separately costs you more, and you are not happy with the performance, then scale back, or perhaps you are doing it wrong. Splitting resources doesn't instantly mean that you will save money, only that you can.