Architecture: different site collections or farms for departments?

On my current project I have an urge to split  one site collection that has been used by all departments in an organization to several... but I never could prove my point of view.
Today I have been learning from https://training.partner.microsoft.com/ , the course :"Architecting a Portal solution" and found a precise rule "how to plan a departmental portal":

Here is 3 options that were covered:
1. Separate sites in a single site collection:
This is a good for smaller environments. If you design a portal for which you expect a large amount of data and number of site to grow, it is strongly recommended that you consider the separate site collection approach

2.Separate site collections in a single farm
Consider this option if all users throughout your organization have good connectivity to a server center with facilities for backups and fault tolerance

!Attention. Even though there is no hard limit on the site collection size - but I prefer to keep the size manageable - less than 100 Gb. From perspective SQL backup\restore -it's still doable. In my project the site collections splitting will decrease the size of the content database. I will create a new site collection in the new content database.
For more information regarding the site collection size is on  Tips on Site Collection Sizing

!Worth to notice: If you have decided to have a several site collection on your web farm, remember that following features can't be shared across the site collections

• global navigation;
• branding;
• security groups;
• content types;
• content sharing web parts;
• site aggregation web parts;
• usage reports;
• alert management;
• workflows.

3.Separate  Web server farms
Take this approach,if each department is in a separate location wand WAN links are slow or unreliable.

Excerpt from Microsoft Office SharePoint Server 2007 Best Practices: "One Web Application, One Site Collection" - the most common trap, largely because it's the easiest to configure for both administrators as well as end-users. The problem with this approach  it that, despite the ease of setting up a single site collections for the entire site hierarchy, it eventually becomes apparent that this setup is not supportable long term from a capacity perspective and provides little or no data segmentation for protecting against loss or corruption. This configuration often results in a need to split up the site collection, which can prove painful as well as difficult to coordinate effectively.

!In case you need to split existing site collection into several - highly recommend this to read - Tips to create a Site Collection in new Content Database

P.S. Even I have mentioned the training link below, I don't recommend to take the courses there. I have found them a kind of shallow...
Actually, my dream is try this one USPJ Academy .But can't recommend it to you, because I haven't tried myself.

What I CAN recommend is Understanding SharePoint Journal. I have bought several issues there - and I love it!
Professional SharePoint Development
Introducing SharePoint 2010