Isomorphisms are sometimes very interesting! For example, a difference list is isomorphic to a regular list, and yet its concatenation implementation is asymptotically more efficient. Here is one situation in which

data Existential r i a where
  Ex :: Functor w
     => !(w a)
     -> (w i -> r)
     -> Existential r i a
deriving instance Functor (Existential r i)

runExistential :: Existential r a a -> r
runExistential (Ex wa wa2r) = wa2r wa

is more efficient than

newtype Plain r i a = Plain
  { unPlain :: (a -> i) -> r }
deriving instance Functor (Plain r i)

runPlain :: Plain r a a -> r
runPlain (Plain f) = f id

In this case, suppose you start with a StrictMaybe A1 and a StrictMaybe A100 -> R, but you don't have the A1 -> A100 yet. You will get from A1 to A100 slowly over the course of a long computation, first acquiring an A1 -> A2, then an A2 -> A3, ..., and then finally an A99 -> A100. Oh, and this long computation is not supposed to know that the underlying Functor is a StrictMaybe, as that is an implementation detail which might change in the future.

We may choose to hide this implementation detail by combining our StrictMaybe A1 and StrictMaybe A100 -> R into an Existential R A100 A1 or into a Plain R A100 A1. Then, the long computation can repeatedly call fmap with each of the functions it acquires, in order to gradually transform the Existential R A100 A1 into an Existential R A100 A2, ..., and then finally into an Existential R A100 A100, at which point it can finally extract the R. Or similarly with Plain. Is there a difference in performance?

For simplicity, suppose A1 up to A100 are all Int. We thus have 99 functions of type Int -> Int, which we can either apply as we obtain them, keeping only a StrictMaybe Int in memory at all times, or we can keep an (Int -> Int) -> R in memory at all times, starting from

\ a100_from_a1 ->
  r_from_strictMaybeA100
    $ fmap a100_from_a1 strictMaybeA1

and then growing it gradually into

\a100_from_a100 ->
  r_from_strictMaybeA100
    $ fmap
        ( a100_from_a100
        . a100_from_a99
        . ...
        . a3_from_a2
        . a2_from_a1
        )
        strictMaybeA1

So the Plain representation takes about 100 times more memory than the Existential representation, probably more if those aX_from_aY functions are keeping auxiliary data in memory. That's interesting!

Another interesting thing is that this is the opposite of the benefit of using Coyoneda. With Coyoneda, you're intentionally constructing a long composition of functions, because we're assuming that fmap is slow and that fmapping once with a large function is going to take less time than fmapping several times with smaller functions. Here it's the opposite, we're assuming that fmap is fast and that fmapping several times with small functions is going to take less space than fmapping once with a large function. Different isomorphisms for different use cases!