I wouldn't call that trivial but "common", and for these cases we could even use something like catMaybes:

> sum . catMaybes

Lenses (imho) shine when you have to write data-extractors for arbitrary-complex and ill-documented APIs with corner cases or things like HTML scrapping. The beauty of lenses is that you get one composable language across libraries. For instance, if your HTTP-library has lenses and your XML-library has lenses, you can write things like safely composing a getElementsByTagName with some XML-parsing and data extractions:

> response ^.. responseBody . xml . folding universe . named (only "p") . text

and the bonus is that if you need to filter, you can do that with a similar mechanism (e.g., filtering based on some html meta-tag)

overall it feels like SQL-for-arbitrary-structures: dense but powerful

I prefer a general polymorphic solution to optimize for global simplicityand consistency rather than lots of different ad-hoc simpler solutions that are more complex and/or less composable altogether.