Warning, this is going to be long...you asked for it...
Answering this question well requires looking at React from a couple of different perspectives. It also requires understanding a bit of the 35+ year history of presentation patterns as well as an understanding of web technology's purposes and intents.
First, it's important to understand that Separated Presentation patterns emerged mostly in the context of creating component models on various platforms. For example, MVC originated in Smalltalk, Supervising Controller and Passive View have their origins in things like Java Swing and Windows Forms, and Presentation Model and Model-View-ViewModel have their origins in binding-based technologies like Xaml, Flash/Flex and modern Web frameworks. Components can be complex and engineers found that it was better to define distinct roles and responsibilities within a component. Take the classic MVC pattern. The roles and responsibilities of a Controller are different from those of a View. The role of the Model is different from either a Controller or a View. Yes, these all may be part of the same component, but they have different roles and responsibilities within that component. They are concerned with different aspects of the component's "life".
Note: I'm using SoC and SRP pretty interchangeably here. This isn't something you can/should always do in conversation. I'm taking this liberty because you will observe that, if you "zoom in" to a specific implementation detail of a system, SoC and SRP are actually talking about the same thing. That's not true if you "zoom out" to look at the bigger picture of a given system.
With that in mind, let's look at JSX first. What is the purpose of JSX? Does it have one or many? My understanding is that it's designed to serve the View role. To really understand this, you must see JSX as neither HTML nor JavaScript. You must see it as a unique View language. So, from the perspective of separated presentation, it seems to do a very good job, namely fulfilling only one role, that of the View.
That's the idea, but is that the reality? If you look out and see how developers are using JSX in practice, are they using it as a View language? My guess is that while JSX is intended to be a View language, it is probably most often being used as JavaScript with embedded HTML (this is what I've seen in most demos/presentations/samples/tutorials). This way of thinking of JSX can lead a developer to mix concerns. It's quite possible that the React component model may even encourage this since the same class controls state and renders it. I think the cleanest way to use React would probably be to treat the component class as a pure JavaScript ViewModel and to extract the JSX rendering logic into it's own class/object/function, which serves as the View for the component.
What I'm getting at here is two things primarily:
So far I'm looking at this question from the perspective of design patterns and Uncle Bob's SOLID, but that isn't the only way to look at it. You can (and should) look at it in terms of web technology purposes and intents.
Some people think that HTML is about rendering. It isn't. A brief review:
Developers I've interacted with, particularly those with extensive server-side or native UI toolkit experience, often get confused about the distinction between Semantic Conent and Presentation. It's no small distinction though. In fact, to hearken back to the previous section, you might think of it like this:
Interesting isn't it? Hopefully, that makes more clear the importance of the distinctions in the web programming model.
There is a whole group of professionals in our community that care intensely about these distinctions. They are the Information Architects, UI/UX Designers, Web Designers, Graphic Designers, Marketing Specialists and Accessibility Experts. Note that these people aren't necessarily the same type of "developer" that is likely to have read Uncle Bob. They might not even think of themselves as a developer at all, yet they are an integral part of our community and the web ecosystem (more important than most developers feel comfortable admitting).
So, when you show JSX to a person with one of these backgrounds or areas of expertise and ask them "Does React violate separation of concerns by putting HTML and JavaScript in the same file?" They are going to say YES.
Someone who is tasked with the job of properly authoring Semantic Content is going to really have a problem with JavaScript getting in the way. A UI/UX engineer who is working with design tools like Sketch or Illustrator is going to be disturbed by the fact they can't write plain HTML and CSS. A designer or artist who wants to control rendering details and has to weed through JavaScript to find the proper HTML structures to apply CSS to isn't going to be happy.
The effect of JSX on this segment of creative individuals is to basically exclude them from the web. It nullifies their tools and renders anyone without extensive JavaScript capablities unable to create semantic content. That's a pretty serious problem. Most of these individuals could tell the average developer a thousand things they were doing wrong with their HTML and CSS because they are experts in these areas. Yet, the overreaching of JavaScript into the domain of HTML, makes it difficult or impossible for many of these individuals to collaborate or create - certainly not on the level of expertese that they actually hold.
Summarizing this perspective:
Ok, we've covered two important perspectives. But, there's another important thing to look at, which I hinted at in the previous section: collaboration.
Most people think that OOP, SOLID and various design patterns have a primary purpose of enabling code reuse. They can help with that. People often also recognize that these things can improve maintainability or extensibility of a system. That's true as well. But more often than not, people forget that one of the primary purposes for SOLID, OOP and many design and architectural patterns is to enable team collaboration.
When you properly separate concerns, you can have more people working in parallel on a given feature. A component model that has a solid separation of concerns can enable greater collaboration between developers, designers, UX experts, etc. They can work at the same time on the same component. At the present time, it's not sufficient always to simply separate these concerns, but keep them in the same file. Because of the way that modern code editors work and the way that version control systems work, it's much better to separate them into different files. Not doing this creates a technical barrier to productive collaboration. Your team will be slower and your development will cost you more money.
The main point I'm making is that how you go about handling SoC/SRP technically, has serious non-technical side-effects, including helping/hindering parallelization of effort.
Ok, let's step back and summarize the whole thing.
Does React violate separation of concerns by putting HTML and JavaScript in the same file?
The technical JavaScript Developer Perspective
The UX/UI Designer Perspective
The Team Perspective
Now, a quick bit of followup to address other comments here:
Now, to the real point. Why is the author of this question asking it? There are a lot of possible reasons. Let's assume that they are honestly trying to decide if they should use React and have some honest questions/concerns.
If you are trying to decide...personally, I would tell you to avoid React. There are a lot of reasons for that which go beyond the scope of your specific question. But, let's look at it from the perspective of your question:
Even if I try to be conservative with respect to what I know from experience happens in the real world, it comes out negative. For me, not considering any other issues React has, this is just too much risk and too much exclusion of potential talent and creativity.