But more important is the separation between the directive and the rest of the code. The directive is specifically about the logic that's directly related to the view. That's not something you want to put too far away from the view.
And of course Angular's html is enriched html: by including directive, you can put databinding, and limited logic (generally about when you show that bit of html) directly into the html. Separating those would be frustrating and a bad idea. If your view is dynamic, that logic should be considered part of the view.
And of course Angular's html is enriched html: by including directive, you can put databinding, and limited logic
Either it's logicless or it isn't, surely. To me, databinding is absolutely the kind of logic that shouldn't belong in a template in the world of strict code/template separation. Another reason why it doesn't really work.
If you refuse to put the former in your view, you're making your code a lot more complex for little gain. But if you put the latter in your view, you're making your view unreasonably complex and hard to read.
Neither extreme is good. You need separation of concerns, but some logic really does concern the view directly.
Even in Angular, where we try to separate the template from its directive/controller, I don't think I've yet run into a case where I can just reuse a template with a different directive. And in fact, if I was about to do that, I should rethink my strategy (and probably just use the existing directive).
It does result in a tight coupling of template and code, but I'm yet to see a downside to that. Separating template and logic has been the dream forever but is never realised in any non-simple project. Embracing that coupling has been great for me.