In order to minimize the time period an attacker can launch attacks
over active sessions and hijack them, it is mandatory to set
expiration timeouts for every session, establishing the amount of time
a session will remain active. Insufficient session expiration by the
web application increases the exposure of other session-based attacks,
as for the attacker to be able to reuse a valid session ID and hijack
the associated session, it must still be active.
It all depends on the risk appetite of the organization. Each organization will do a risk assessment and decide what type of data they are protecting and what their customers find acceptable in terms of usability. For instance, Gmail may not expire their sessions because it is deemed that the benefit of users not having to log in each time generates more revenue than the reputational losses they have when a Gmail accounts is hacked due to non-expired cookies. Of course the content of an email inbox might be sensitive or it might not be, it's debatable.
Bank applications on the other hand are in 99% of the cases containing money. Furthermore the reputational outfall of "bank X customer gets hacked" generates a lot more unrest than the Gmail example. Customers will start calling the bank worried, they might loose clients who believe their system is unsafe etc...
In the end it's just looking at your threats and vulnerabilities and assessing what the cost and benefit is of implementing mitigating controls (which in this case is the expiration date of a session).