In a larger system, it is much easier to:
Share features and code. You will reinvent the wheel a little less. For example, if you have ten applications which must have an access to the database, you have to specify the connection string in all of them, i.e. ten times. Or you have to create a separate library and reference it ten times again.
Consolidate workflows, including the deployment process.
Manage the system: less applications to manage is generally easier.
Unify the user experience. When an employee has to deal with ten different applications, he may easily be lost: what application to run to do A? In what application is available the option B? But don't overunify. No one will appreciate Word, PowerPoint, Outlook, Publisher, Visio, Project and Groove as a single monolithic application.
In a bunch of small systems, on the other hand, you'll find that:
You can abandon a whole system if you don't need it any longer. Or start from scratch if the codebase becomes unusable over time. This is of course only true if other systems do not rely on this one, or if the interface is light enough to be easily rewritten in a new version.
You can form a team of fresh developers and expect from them to understand the existent codebase in less time. If it's a part of a large project, chances are they will require more time, unless the overall large codebase is done extremely professionally and refactored very well (I haven't seen such codebases in my life).
The system administrators will be able to relocate the applications easier. The larger system, on the other hand, either scale well on multiple servers, or not.
The developers can migrate the codebase to new standards easier. Migrating a large codebase is always scaring. Instead, when you have to deal with a small codebase, then another, then another, and so on, it becomes less scary.
This being said, such comparisons work only in general cases, but your decision must be taken not from pools, but from your company assets. How is it organized? Are there many small developer teams or a few large ones? Are there strict guidelines about coding style and similar things?
It also depends on the application itself. For example, it would be absurd to ship all Microsoft Office applications as a single app. But it would also hurt productivity to, for example, separate Adobe Photoshop in an application for drawing and another one for photos retouching. IMO, the decision to unify or separate a product must be a business decision, not a purely technical one.
Finally, I also want to answer to the second comment of the original question:
I'm kindof assuming that linking data within an app is less effort than linking data between apps
It is not always true. If you're dealing for example with .NET, it is not unusual to ship a single application where different components are exchanging through WCF. In this case, this is comparable to a set of separate applications communicating through WCF.
Of course, when you have to deal with multiple applications, you have to establish some way for them to communicate, whereas having a single monolithic application does not force you to do that. But would you really be able to write a large monolithic application?