For example, sure, you can think of a list as a "monoid" where the add operator is concatenation of two list. But adding two lists is not a fast operation even using specialized functional data structures. So making concatenation a primitive for equational reasoning just results in really slow code.
Exactly! The thing is this book gives a method where you care about value semantics, keep the ideal representation, and then care later about how it's realized in the hardware!
For example in mathematics if you write "C = A + B" and then you ask what A is, it's still always going to be the same.
To make this work in programming you basically have to make all your data structures persistent[1]. AFAIK you would need a store the list as a finger tree or something if you need fast concatenation and that will still only be O(log(n)) [2].
[1] https://en.wikipedia.org/wiki/Persistent_data_structure
[2] http://hackage.haskell.org/package/fingertree-0.1.4.2/docs/D...
[3] https://stackoverflow.com/questions/28406512/why-does-concat...
There is a memory issue because of this, but this problem isn't exclusive to FP languages. Many languages solve this with something called garbage collection.
Immutability is therefore the axiomatic foundation of FP.