The issue I was facing in a previous life was the turnover. We had data scientists, DBA and many specialized roles stay pretty long, where devops moved away at about twice the rate, and work life balance was mentionned in many exit interviews.
I agree with you that it's extremely formative, and having devs involved basically from start to end of the service surface gives a lot of flexibility. The downside being that it requires a ton of different skills as well, and while people learn, many won't get comfortable with it even after months.
This makes it specially tough when people get called at 3 in the morning to deal with an emergency while they've already spent half the night sleep deprived from their kid puking all night. The worst part being that while people could understand wanting to skip turn one or two times, engineers with small kids will have enough going in their lives that most on-call instances land at a time they're busy dealing with more important matters.
When doesn't this involve devs? If you have ops separate and isolated from the development effort, a devs representation will have to get involved at some point.
That's why they have to be the same team. Your dev team needs to: 1. understand how to write code that can be debugged and recovered in a crisis, 2. learn to write code that doesn't cause the crisis in the first place, 3. have the motivation to do so because they will be the ones paged.
Anything else produces are far worse experience for everyone involved, especially customers.
The problem I've seen with DevOps is that some fief-builder sets up a "DevOps Organization", which is literally the opposite of what DevOps means.
Having engineers understand what makes a service resilient and easy to manage, as well as giving them incentives to produce high quality code doesn't require them to do SRE. In particular, being close enough to the SRE team, getting inputs when building the feature, detailed feedback and requests on live services, and the blame when shit hits the fan, are a more scalable way of doing it IMHO.
That's exactly the issue that DevOps aims to solve, though. When you have developers who have no ownership or responsibility once the software is running on production, it becomes a "throw it over the fence" situation, and devs don't care about the operational side.
Logging? Who needs that, if there's a bug report I'll reproduce it on my local machine (and if I can't, CLOSE-WONTFIX!) Performance monitoring? That's an ops problem, tell 'em to buy better hardware. Application crashes? Works on my machine, probably a bug in the server config; ops problem. Tell them to set up a scheduled restart every hour.
You still need dedicated operations staff who deal with the overall system health and design, but yes, a developer needs to be involved when a DDOS brings down the service, because how should the system behave under heavy traffic? Can it serve up cached read-only pages? Did someone find a very CPU-intensive public endpoint that is being exploited and needs to be fixed? Only your developers can answer this question, not the ops team.