I would argue the contrived example below actually demonstrates that lens enables code that is more functional-y. See how we can use over in operator form (%~) to update the value of a field with a function? This example isn’t complex enough that I’d necessarily reach for lenses, but if I was going to create an entire library for creating and manipulating shapes I would.

You might want to look more closely at optics. While I can understand the complexity-based arguments against them I have never heard someone dismiss them as being a crutch for imperative-minded Haskellers. (Do such people even exist?)

{-# LANGUAGE FunctionalDependencies #-}
{-# LANGUAGE TemplateHaskell #-}

module Contrived where

import Control.Lens ((%~), (&))
import Control.Lens.TH (makeFields)

someFunc :: IO ()
someFunc = putStrLn "someFunc"

data Point
  = Point
      { pointX :: Int,
        pointY :: Int
      }
  deriving (Eq, Ord, Show)

$(makeFields ''Point)

data Threegon
  = Threegon
      { threegonA :: Point,
        threegonB :: Point,
        threegonC :: Point
      }
  deriving (Eq, Ord, Show)

$(makeFields ''Threegon)

-- Without lenses
shiftX :: Threegon -> Int -> Threegon
shiftX tgon val =
  tgon
    { threegonA = a {pointX = pointX a + val},
      threegonB = b {pointX = pointX b + val},
      threegonC = c {pointX = pointX c + val}
    }
  where
    a = threegonA tgon
    b = threegonB tgon
    c = threegonC tgon

-- With lenses
shiftX' :: Threegon -> Int -> Threegon
shiftX' tgon val =
  tgon 
    & (a . x) %~ (+ val)
    & (b . x) %~ (+ val)
    & (c . x) %~ (+ val)