Sooner or later a company has to deal with multiple applications written with different technologies
A portal should let the architect define multiple applications that will be in charge of rendering a fragment of a page. The first benefit is that multiple parts of a large projects can be easily divided into teams, the aggregation work will be done by the portal.
A portal framework should be able to aggregate any type of content, but in order to make the components (applications) more unified the portlet specification was born. It enables those components to use a common API and make those components runnable within any portlet container implementing the specification such as Red Hat (JBoss Division), IBM, Oracle...
The portlet specification defines a simple low-level API on which web frameworks can rely, this is not a surprise that you can run Struts, JSF, JBoss Seam, Wicket, WebWork, GWT , Spring MVC, (PHP to some extend)... applications as portlets. It is then possible to mix applications written with different technologies on a single page transparently to the user. Soon or later a company has to deal with multiple applications written with different technologies. This could be the result of a company acquisition, dying technologies that need to be replaced or multiple teams that can't agree on a common framework.
Many companies keep using a framework just because they have been using it for years or require users to access a separate portal to use applications coming from a company acquisition.
This aggregation capability also allows for wider choice when shopping for applications. If you are a Struts user and find the forum application having all the features you need but written with JSF, this shouldn't be a showstopper. Another benefit is that multiple teams can work on their preferred framework without necessarily having to come to an agreement.
To be able to write an application in JSF, Struts, PHP or any other framework, someone needs to provide a piece of code that defines the relation between the portlet specification and the framework, we call this piece of code a 'Portlet bridge'. The portlet Bridge uses the low-level Portlet API to let the developer forget about it (Like most Web frameworks make you forget about the underlying Servlet API).