TL;DR: If you are asking yourself whether you need two solutions, you don't. If you do need two solutions, you will not be asking yourself this question.
SAP's Stefan Hagen, who we liked to refer to as the "C4C pope" while he still worked in the C4C team, basically said all that needs to be said in his 2015 blog post. Yet, a while ago a customer requested a workshop on exactly this topic because they thought having one solution for Sales and a second for Service would make their system more stable in case a deployment fails, at least they wouldn't have to test Sales and Service with every deployment.
In short, it doesn't and it doesn't have an impact on testing.
(Psychology explains why they thought they had a problem when they didn't, but I'll elaborate on that in a later post.)
Deployment Errors
When a deployment fails in your target tenant, the tenant is in an undefined state and you shouldn't use it until the issue is resolved and the deployment finished successfully. Period.
Having two solutions achieves nothing here. Even if you are just deploying Service (as in my customer's example) and it fails, the entire tenant is affected and Sales should not work either - no change from having only one solution.
The reason for this is that all solutions in a tenant are blended together with the SAP Standard and form what you perceive as C4C. And if one component of this blend is faulty, the blend as a whole is faulty.
Deployment Time
Also keep in mind that having two solutions means that you have to do two deployments. You should not try to deploy them in parallel. Especially with large solutions this could mean that the entire deployment process might not be finished within one day.
Testing
Multiple solutions do not facilitate testing either. If you have one solution and know that you didn't change anything in Service, you do not need to test it. Again, having two solutions achieves nothing here.
So this is rather a question of discipline and documentation.
Conversely, if you have two solutions (again, Sales and Service) it is perfectly possible to interfere with the Sales part from the Service part and vice versa. So again discipline and documentation are required and it is not technically possible to guarantee a "Service solution" brings no changes that Sales needs to test.
Cross-solution communication
Different departments of the same customer might argue that they want a solution just for their department (e.g. Sales and Service as mentioned above). They think they are autonomous. I would argue that hardly any customer has processes that strictly separated so they will never need to interact with one another.
If you have one solution, it is not an issue to create a follow-up quotation (Sales) from a service request (Service) and fill some quote extension fields.
If you have multiple solutions (quotes extension fields in one and service requests in the other), you cannot just retrieve + modify the extension fields of the quote you just created, you have to use a web service (!) to do that. The same goes for simply reading the extension fields.
Performance
As said above, all solutions are blended together to form C4C. This means that upon saving, the relevant coding of all solutions is processed. Especially if you make modifications to "general" objects like Customer you might find that both Sales & Service added extension fields in their solutions and implemented corresponding events. Those events would all be processed in case of a save. And since especially Customer is not know for its great performance, you end up with double the delay when saving.
When you might use two solutions
As said in the first line, you will know when you need to use a second solution. If you don't, then don't use it.
One rather common case: You have an error that you can only reproduce in the TEST tenant, but its not possible to create a hotfix to see if your correction to the error would work. Or you find that you cannot access a certain association in the debugger. The only alternative here would be to make a correction in DEV then deploy to TEST, possibly in multiple iterations.
In this case you could go ahead and create a second solution in your TEST tenant and implement your correction. If it works, apply the fix to your DEV tenant and delete the solution in your TEST tenant.
Another example would be a third-party add-on. Even though SAP encourages you to develop and sell your add-ons through SAP Cloud Platform, the benefit of having an add-on "in the system" is that you own it and can control and modify it. Such add-ons could easily live as a third-party solution as they would hardly require any modification (except for feature and security updates by the vendor).
However, this might not work in all cases and needs to be tested thoroughly. Possible problems include: solution events triggered in the wrong order (you cannot influence the order) or infinite loops (solution A modifies object, triggers solution B, modifies same object again, triggers solution A etc.).
My customer ended up listening to my advice and stuck to one solution and they are still happy with the setup.