Bearing in mind that “handling” the locks may mean a deadlock is detected and the transaction is aborted by the DB, which the application has to handle by retrying in a correct manner. (Which is another point often missed in naive application code.)

Not exactly - the database doesn't know whether you want to block that account update or not. So, speaking very roughly, it allows you to choose general level of such a blocking behavior. It manages those locks, very coarse, at serializable and some of those locks at repeatable read. At read committed it manages basically only small set of locks just to avoid dirty reads (plus of course all the WAL/rollback/etc. which is the main features and the point of the database with the isolation levels being just the icing on that cake). Isolation levels is a tool, and you choose what is needed and suitable.

The serializable actually is a pain in the neck for any meaningfully serious large enterprise application. The decreased concurrency kills overall performance, and I haven't seen any such application running in serializable (and for example at my current job our customers are running our application on servers with low tens of TB RAM (largest so far was 40TB RAM) per single machine with high hundreds of cores with thousands of users - in serializable that would slow to a crawl as it wouldn't allow to achieve the concurrency the database on those machines is otherwise capable of). While not precise illustration it still communicates my point - the serializable against read committed is like the global Python lock against the fine grained locks in normal languages.