postgres query performance: view vs function
A view cannot help you producing an aggregate based on unknown parameters (business_id, start_date and end_date).  It is nothing else than a given query, stored permanently in the database for later reuse.  (Well, the implementation is more complicated, but that does not affect their usage.)

Considering your query, the furthest you can get with a view is

CREATE VIEW staff_commission AS
SELECT 
    user_id AS staff_id,
    business_id,
    amount,
    start_date,
    end_date
FROM transaction
WHERE
    type = 'staff' AND
    kind = 'commission';


Everything that is known beforehand is there, plus the columns you need for producing the desired output.

For obtaining the latter, you have to create a function in any case (optionally, working from the view).  Building on the view makes sense when you have several queries that filter the date the same way.

The performance of all these will be the very same.  If the indexes makes sense or not depends very much on the actual data.  (I am pretty sure you don't need all of them, though.)  Without knowing anything about those, it is very hard to guess which improvements are needed.  Try what you have, check the EXPLAIN ANALYZE output and see if there is something missing.  

Finally about caching: PostgreSQL is very smart about this.  Going into details would fill a chapter or two in a book, but I would not worry about this until I see too many disk reads (which can be seen from EXPLAIN (ANALYZE, BUFFERS)).