Well one reason for having multiple Applications within one DB could be sharing the same base data for different Applications.
Of course you could import the data 20 times to 20 different DBs which is most likely according to your statement what you would do and I admire anyone being allowed to waste resources woefully. If you have Sales data and different Sales departments which each use a subset of the available data, go ahead with your approach and let us know what your customer thinks about your design strategies. I guess your most basic design aswell includes one DB File that can grow to 16 TB before you realize you've reached a limit, alternatively you have never been close something like that, take your pick of "most basic vanilla design" sincerely.
Um, no?
In that scenario you'd probably separate the sales departments with a simple field in the relevant table (invoices, maybe?), then in the SP either supply the department you wanted or (more likely) allow the appropriate users to see all departments.
Applications are front-ends, independent of databases. If they use the same data they use the same database. Or am I misinterpreting your point?
Note I did say use the minimum needed features. Simple does not mean brainless. Elegant design is both simple and efficient at the same time.