I've worked with a "devops" team that spend hundreds of thousands of dollars on puppet consultants and never got it working. Another team spent it's time badmouthing various technology choices, but then didn't realize that our customer's onsite deployment dictated the technology choices and chose the wrong tech.
The real reason devops exists (what used to be called Application Engineering) is because development is pretty clueless about the customer's runtime environment. They don't really understand the tuning necessary to create a production system.
Example: very few developers understand how big your DB connection pool should be, because they tend to only test one connection scenarios. That's assuming they're actually know enough to use a connection pool. And they almost never handle failover scenarios.
DevOps should be the purview of the senior engineers. If you're building without an understanding of your deployment environment then you're screwed. And more importantly, you're not taking advantage of platform features.
As an example, deploying to SSDs (which everyone should be doing) means your database performance has just gotten an order of magnitude better for free. You need to retest and get rid of a lot of those performance-related changes.
Let's put it this way: one monolithic Java/spring application I worked on was basically a SOAP server with a UI that took up gigs of RAM. It was that big because the scaffolding required to handle all that was, well, huge. But really, it was essentially a web server that served pages to connected clients. All that other shit was overhead...so on AWS it got transformed into a few lambda functions and REST apis. Without an understanding of the deployment environment (and the possibilities associated with that) it would never have happened.
TL;DR: senior engineers should be the devops people, because how and where you deploy software should determine how you should make software.