Back to Basics - 1 : Right from web apps and site collections

Basically a SharePoint Web application is a logical abstraction on top of IIS. Physically, a Web Application is a "collection of one or more IIS Web sites configured to map incoming HTTP requests to a set of SharePoint sites."  A mapping of each SharePoint site to one or more content databases that are specified within Central Administration.

Ideally we should primarily utilize separate Web apps for exposure to differing environments for example have intranet and extranet Web apps using HTTP and SSL respectively. As far as scalability is concerned, Web apps support up to 300 content databases and a recommended limit of around 2000 site collections per content DB assuming your infrastructure is up to it.

Adding additional Web apps adds additional administrative and infrastructure burden and - wherever possible - I would suggest using as few as possible. The decision to go with Web apps vs. site collections should be made as part of a wider discussion around your infrastructure.

When we need more than one web application? if there a  need of

• different authentication provider
• different service applications group association
• application pool isolation (e.g. for fault tolerance or security)
• different url (with alternate access mappings)
• different web.config
• different bin folder
• differing throttling settings
• differing security policies. (e.g. set up a "finance" Web app with a locked down user policy, whereas a collaborative Web app may be less restrictive) 

What additional overheads are associated with a Web application?

• Additional RAM required per Web app (even with 0 users) > more hardware required.
• Timer jobs (around 30 per Web app, several of which run every few minutes (e.g. alerts & workflow) and many which run daily (e.g. workflow processing and gradual site deletions)
• More Content databases - per SQL instance limit, backup concerns, storage space
• IIS sites > administrative overheads (host headers, IP addresses, SSL certificates, Web configuration files, assemblies).
• Other operational overheads: DNS / request routing; SharePoint solution management 

I would suggest having different site collection for different department, because

• site collection is root level for many settings starting from permissions,  site collection features like branding, master page, css, etc.
• Also, there are features like Move-SPSite which moves one site collection to a separate content database.
• If your SP Farm grows in time, it will be more scalable if each department having its own site collection is moved in separate content db.
• With this kind of structure, you will prevent having huge databases, have better performance, etc.