So Html.map and (SmallComponentMsg → msg) functions are basically the same thing.
The whole point of my post was that they aren’t. With Html.map you are locked into only one “level” of message type. Taking functions lets you take different ones (e.g: one for wrapping internal messages, one for some external result), which is more easily flexible. You can of course emulate one with the other (your component can have a message type that has branches for internal/external and then have map calls disassemble that), but some ways of doing things push you into certain patterns and mindsets, picking the more natural ones can make things easier.
So I guess, my question becomes: why is it frowned upon in the Elm community to divide your development into components?
It isn’t, rather, it’s a bad idea to automatically split all of your code into components, as it adds complexity and forces you to write a lot of boilerplate for little gain. Making each page it’s own isolated component in a multi-page application, for example, is generally a bad idea. They are only going to be used in one place, and often end up needing to touch shared parts of the model.
If you have something that really makes sense as a component, something that needs to be done in many places across your application and is reasonably self-contained, then yes, make it into a component.