Sorry--that was a generic "you" there, not you-specifically. I'm saying that this is something everybody needs to understand because writing state-munging code is intrinsically harder to do correctly.

He's not just "splitting the code into two parts", though. He is consciously and specifically defining a core based on functional principles that avoid mutating state (which is harder to measure and reason about). That UI layer, his "imperative shell", is where state is managed, rather than embedding side effects into his business logic. (If you watch the Boundaries talk you'll see he frames larger applications as sets of functional cores surrounded by a layer of imperative routing between them.)

"Functional core, imperative shell" sounds quite dogmatic and not "getting it" is no reason to fear for anyone's code.

Just like the OP article argued that TDD can become an all-solving hammer in the eyes of people, so can functional programming. In this particular case I can think of a whole host of applications where the core should definitely not be functional (and, for what it's worth, immutable state is not inherent to functional programming, or at least it didn't use to be). If it were so, ORMs wouldn't be a thing.

I can't think of a single case outside of a systems or game development context (and a number even there) where anything I have written was improved by tightly coupling state mutation to business logic. Not one. Rather than trying to invoke "dogma" so very seriously, feel free to suggest one. But it's a really long row to hoe: if you are conflating state mutation and business logic, you have entire classes of errors that clean separation doesn't and it's harder for you to meaningfully test for correctness. Not firing that gun into your foot seems very obvious.

And functional programming has never encouraged mutation of data model objects. Not at any point. Mutation of data model objects is and can be nothing but a side effect of a function. There are cases where you can't not mutate a model, such as when that refers to a system resource (a console, a socket, etc.); those are not your data model. Those are dependencies that your application uses to create instances of your data model and feed them through a set of functional processes. Almost like there's an imperative shell that deals with and controls side effects, wrapped around a core of pure functions that manage stateless transforms based on your business logic...?

ORMs (in the mutating, own-your-object sense like an Active Record model) shouldn't be a thing because they're awful creations that aggressively they encourage bad, muddy code that's harder to test and trace and debug. Once more for emphasis: the second you mutate a data object you have made testing an order of magnitude more difficult and now you have to live with that forever. Active Record requires this. There are places where you may choose to embrace this, but it's a good way to shoot yourself in the foot.

On the other hand, data mappers (Anorm, DataMapper, Slick) live outside of the cleanly tested, no-dependency core (and its data models) and are used to feed objects into your business logic and record the results back to an external data store.

If you aren't using plain old objects to encapsulate your data, you're asking for it.

You know what? I had prepared a longer answer addressing most of your opinions here, but I'd rather not[1] so I'll just say I disagree and leave it at that.

[1] After all, I can't conclusively prove an imperative codebase is more maintainable anymore than anyone can do it for a functional one so this would just be another entry in a 50-year-old flamewar.

You might not be "conclusive", but a cogent argument like "I'm adding classes of bugs that don't exist otherwise but I get X for doing so" should be pretty straightforward. If it exists. My contention is that it doesn't, but I'm always willing to change my mind. I'm pretty emphatic about this because I've spent twenty years learning that every other approach in common practice will eventually screw you catastrophically.