None of the libraries or patterns I mentioned above are designed for the purpose of exploring category theory. Though some people do do that, but they tend to live in their own world.
A lot of Haskellers just happen to exploit bits of CT it because its a great framework for writing and reasoning about code. Some people do use Haskell as a way to explore category theory but for example Tekmo isn't writing pipes as a means to explore the theory of free monads, they've been well studied since the 80s. I believe he just happens to find that they are an excellent way of chaining together bits of control flow.
At that heart of the problem he's tackling is very practical problem that's tied to data flow and resource management. For example, I've written a library against pipes which handles resource management of ZeroMQ sockets for a large distributed system and find that my code under pipes is much more manageable.
Okay, sure, resource management is what I'd call a practical problem, and pipelines are familiar from Unix (and Go). It looks like this pipe library has a nice practical example: enforcing the category laws means that it handles terminating pipelines consistently:
A lot of Haskellers just happen to exploit bits of CT it because its a great framework for writing and reasoning about code. Some people do use Haskell as a way to explore category theory but for example Tekmo isn't writing pipes as a means to explore the theory of free monads, they've been well studied since the 80s. I believe he just happens to find that they are an excellent way of chaining together bits of control flow.
At that heart of the problem he's tackling is very practical problem that's tied to data flow and resource management. For example, I've written a library against pipes which handles resource management of ZeroMQ sockets for a large distributed system and find that my code under pipes is much more manageable.