I wonder which of the two perspectives is most useful for the development team that is going to implement my stories?
In all honesty? None. Most useful is the conversation you (as the PO) have with the dev team about the user story, explaining them what needs to be done and what the acceptance criteria is for this particular functionality.
A one sentence long statement of what you want is usually not enough to understand everything that needs to be implemented. User stories are not detailed requirements. They express what the user needs the application to do for them. They are from the "user" perspective, that's why they are called "user stories".
Going on your example, my idea of an user story might go something like this:
As a user of the application, I want to receive relevant marketing emails so that I can profit from the best deals
... or whatever.
Nowhere in my example is there specified "how". How the email is formatted? How is the email styled? How is the email sent? These are part of the discussions the PO and the dev team need to have around the user story when it's time to implement it. As a user I really don't care about that, I just want the application to do it somehow. It makes business common sense for the email to carry your company's branding, but that's your acceptance criteria as the provider of the application, not necessarily mine as the user of the application (this shows another problem with user stories, sometimes they are not written by real users, but by someone from business who "thinks" they know what the real users want).
Then, not everything in the backlog needs to be a user story. How about bugs? Do you write bug issues from the perspective of the user? It's ridiculous, right? Somehow though, people try to force all features, functions, requirements, technical changes and implementations, etc into user stories and think it's OK to do that. But it's not. It just creates administrative overhead because instead of specifying what's needed in a natural language, then discuss further details based on that, people spend a lot of time to write "the perfect user story" on a constraining pattern. Sometimes that goes overboard and you end up with anomalies like "As a developer I want a back-end API so that I can implement a rich front-end", which is worded as a user story, but it's not a user story.
An item like the following is just fine:
All email communications to users should be properly styled/formatted
Don't overthink it. As long as everyone understands what it means and what needs to be built (which rarely is understood from just one sentence - thus the conversation you need to have), it needs not to be forced into a "As a [user type], I want [some thing] so that [some reason]" pattern.
If you find it hard to express it from the user's perspective, then maybe don't write it as a user story.