The key is that a portal solves many key problems that large, loosely integrated content providers face.
Portal builds upon J2EE, so theoretically, you could do everything a portal does in your own, custom built applications. But who's got the time? It's like Struts of JSF - you could do all that stuff on your own, but why bother when someone else, who is smarter and better looking than you, has done it for you?
Content management headaches, common look and feel, personalization, customization, ease of deployment...These are just some reasons to use a portal.
A portal solves some very big, very significant problems that clients face. But it's not for everyone. But when it fits, it's a good fit.
A centralized application, which has access to various other applications within the same enterprise in order to share the information across the applications, is often required. More importantly, the various users who access the different applications with different roles may prefer to have a single access point to all of them over the Internet. They almost prefer to personalize the applications and furthermore, to have the coupled applications coordinated. Meanwhile the administrators would like to have administrative tools all in a single place, in order to administer all the applications. All these would be achieved through portals.
What is a portal?
A portal is a central place for making all types of information accessible, where users locate relevant content and use the productive applications. Due to their ease in development, richness in functionality, flexible customization of interface and pluggable architecture, portals are gaining attention among administrators, content consumers, developers, etc. More interestingly, portals offer compelling basic benefits such as reduced operational costs, improved customer satisfaction, and streamlined business processes.