We usually take all software design principles at a face value and rarely think about the reasons why we have them in the first place.
The reason why we need software design principles is because software changes. Software design principles are methods of organising software that make it easier to implement changes.
When it comes to changes it seems that the golden rule that makes things easier for humans is: things that vary together should be together (and things that tend to vary separately should be separate). Its interesting to think about why this is the case, but I'll skip that and take it as an axiom.
There was an article (which I can't recall the URL of) that argued how all the SOLID principles stem from this basic rule.
Single responsibility principle: it follows directly from the above rule: A class should have only one reason to change (keep things that could change separately separate)
Open/closed principle: Interfaces should vary significantly less than their implementations, so that both producers and consumers of those interfaces can vary independently of each other. e.g. Shape can have a method draw that takes a canvas interface: now we can vary both the canvas implementation and the different shapes independently.
Interface segregation principle: don't put too many things in an interface, they might vary differently. Make separate interfaces based on consumer types since change in consumers are more likely to affect changes in the interfaces they use, and having one interface for two types of consumers means two separate sources of change that vary differently.
Map / filter vs for loops is simply this principle applied in the small. The code to initialize an empty data structure, iterate through all the elements applying a function and then store the resutls in the data structure is always the same. The only thing that changes is the function that defines the transformation. Since its a concept that is very common and never changes, it should be separated from the transformation itself (which changes often and depends on the problem domain) and be given a common name (map)
It then follows easily that separating the component template from the code that manages component state doesn't really help. Its fine in server-side languages where the template is simply the final function in the data transformation pipeline for that request, with multiple potential views on the same data (html, json, xml etc). However, on the client side most of our code manages changing state closely tied to the DOM based view: for example, the sort column and sort direction of a table, or the current item selection, etc. The kind of state we keep is directly tied with how we present things (sortable table? => sort column and sort order; expandable tree? => expanded/contracted state for all branches, etc). As our view/component requirements change, the state we keep for it (and the way we manage it) also changes.
And since things that vary together should be together...