How this should have gone
Ideally it would have started with an individual email to John (and granted, I'd question whether this wording was entirely appropriate even then, but at least then you and John would have had room to privately go back and forth over it in a more relaxed way, as John wouldn't feel like he got torpedoed in front of the entire group):
John, according to my conversation with Chris, he asked you to take ownership in organizing project delivery of the [small project name] and we need your help in this space to double-confirm that everything is ready. You can work on organizational details with our [scrum muster name] and business [stakeholder name] and double-check individual development status with [individual developers names]
After a response from John, the inclusion in the group email:
John will be organizing project delivery for [small project name].
At most you might have additionally said something like:
Since he's being brought in cold for that given he hasn't been on that project prior to now, please prioritize any requests from him.
Or something similar, which puts it on the group to act accordingly to expectations and to the situation with bringing John in like this, rather than on John individually, and doesn't speak negatively about John in doing so (avoids implying he's "not up to speed" or something similar by not using related language). Personally I wouldn't even go this far, and would instead individually contact related members regarding how you're dropping John in on this cold at the last minute, and expectations in helping him navigate that if he needs it, rather than dropping it in a group wide email.
The upfront issues I'm seeing here with how this was originally done
Rather than acting as a flat structure leader/coordinator, you very easily came across as if you were not only acting as John's manager, but very easily could have also come across as effectively passive aggressively chiding him for not doing his job, per "according to my conversation with Chris, he asked you to take ownership in organizing project delivery of the [small project name] and we need your help in this space". In a public space email before the entire group.
There are degrees to which, even in a flat structure, the leader has to give what amount to being hard direction, which can easily be called commands. I'm not going to debate the pros and cons of flat structures. Personally I don't mind a teammate at the same level saying what they need from me in order to finish a project, but I feel like it does easily set things up for miscommunication, versus being able to route things through a clear superior.
Also, honestly, I'm confused. In your redacted email, you're claiming he was asked to take ownership in organizing project delivery of this specific project. In your question's text, you simply say that during his hiring process it was explained that he would be involved in project delivery of similar "small projects", not this project specifically:
but during his interview with my manager, before he was hired, it was agreed that he will take ownership of similar projects
If John wasn't already aware of this project (and per your own question, he certainly hadn't previously been involved in it) and aware of his expected involvement in it like this, then this really does come across as at best just dropping it in his lap as if he was expected to already be on top of everything… in front of the entire group. I'm not going to say it's highly inappropriate, but it is very easy to see how someone might be caught off guard and then take it very poorly, and I can't really fault such a reaction.
At worst, this does come across as calling him to the mat for not doing what Chris asked, which would be highly inappropriate in a group email.
Particularly given that you just pulled someone in with "a couple days left" on delivery and asked them to organize project delivery. Depending on what's involved with delivery of this project, this could easily feel like getting blind sided in a very negative way, and it would be easy to question what the intent was behind how you approached doing it like this, in such a tight situation.
Avoiding this in the future
Don't use group emails for asking people to take on roles on specific projects, even if you think they've already been asked/tasked to generally take on that role for projects fitting in that space. Discuss it individually, discuss the specifics individually that pertain to that individual, then explain to the group that the person in question is taking on that role for the project. Don't tell someone what to do in a group email, explain what will be happening in the group email where it pertains to the group. This distinction may seem subtle but it's still actually significant in how it informs what you say, how you word it, and what you omit. At that point, even in terms of coordination, all anyone needed to know is that John is organizing project delivery.
To another extent, you also are kind of implying that John doesn't know how to do something that you've just gotten done saying is considered to be part of his job, with the last sentence. Always assume competence of others publicly, especially when sending an email to a group: it's not the right place to effectively explain how to do something to an individual. I realize you probably meant it as some kind of an introduction to the people involved, but presumably John has been working with these people for a few weeks now, albeit not on the given project, and has had enough onboarding to be able to look up the project details and figure out who he needs to talk to himself. Failing that, let him come to you with questions. In an individual email this wouldn't be so bad, but I can see where some people would feel embarrassed (and the point isn't about whether they're right or wrong to: the point is avoiding an entirely unnecessary and easily anticipated point of tension) with this being lumped into a group email in front of everyone else.
Part of being a good leader is making sure that team members feel like they're being made to look good in front of each other by you
…and I do feel like you let John down here on that, at least by degrees, in multiple ways. This is especially important with new employees who are trying to fit into the group and still working on establishing themselves. This follows generally from the concept of praise in public and criticize/critique/reprimand in private.
When in doubt? Just err on the side of keeping the communication—or at least anything beyond the barest minimum—private. It also helps keep the public communication channels cleaner. I realize that one concept of Agile, including Scrum, is being aware (or at least able to be aware when it counts) of what's going on with everyone else, but a side to that is not overloading your entire Scrum team with extraneous details that stop it from being actually agile. Anyone would tell you: my writing style could be described as wordy, loquacious even (no, really?). But there's a time for brevity, and a lot of what makes Agile actually agile hinges on exercising it appropriately and trusting people to speak up or ask if they need more, rather than doing things like micro managing them.
