Just a few (obviously there are more, but my time is limited) benifits I see in using a (SSAS-) Cube versus using SSRS are:
- Performance. During cube processing SSAS will (when setup properly) pre-calculate and physically stores aggregations of facts (Amounts, Quantities, Money). These aggregations, for example Turnover by Year and Region, are used when an enduser queries the cube for this type of information. Therefore the query responsetime can be very short.
When the query is fired SSAS does not have to calculate the outcome from the underlying details (like Tranact Sql has to do), but can take the values directly from the stored aggregations.
Besides that SSAS stores query-results in a cache. The next time the same type of query is fired, it will try to get it from the cache.
- Advanced time-calculations. It's very easy to implement advanced time calculations like 12 month rolling average (trend !), yeartodate and references to paralell periods in previous years. This is typically the stuff decision-makers in the organisation want to have. Imagine, how many (transact)-sql-queries are required for calculating rolling averages for each of the previous 12 months (2009-May..2010 April) => 12 ! using the cube as a datasource => Only 1.
You can use the security setting to give end-users acces to only those parts (slices) of the cube relevant to them.
Endusers can use Microsoft Excel:-):-D:-) as a powerfull front-end tool on top of the cube. Besides that the same cube can at the same time be used as a datasource for SSRS and Sharepoint (KPI-) webparts.
Getting back to your question on ‘processing and publishing’ a cube does ? Once you've created a SSAS solution you have deploy it to the AS-server. Once deployed the metadata is available on the AS server. In order to also get actaul data in your cube, you have to process it.
The deployment properties of your Visual Studio AS project determine what should be done once you select 'Deploy' from the menu.