Yes, I do agree that the devops culture limits developer from gaining insights into the underlying infrastructure directly but devops is not about developers working individually and devops working individually. It is more of a give and take. As much as I have worked, the developers have always been informed of the underlying architecture, infrastructure and it's limitations. Whenever there is an issue the RCA is shared with the developers and many times the developers are also involved in the RCA process.

The developers do gain insight into the infrastructure but have limited access to the troubleshooting and debugging on the infra. And that is the whole point of devops. Let the developers do what they do best, that is coding. Leave the rest to devops. But I do agree that the coding will be even much more efficient if developers had an internal view of infra as we have. But that is again a double work to be done: coding and infrastructure. It should be more of a give and take. Understanding the coding constructs also helps us (devops) build a better infrastructure.

To your second question: According to me CICD is meant to save your time, efforts while development and to prevent inconsistency across environments. CICD may look like a long, time consuming process now but it surely helps to maintain equality across environments. For an individual development front, I believe a small pipeline should work, it reduces your efforts and maintains consistency. In the end it all depends on your work environment. If CICD benefits you then use it. If you think it is more of a hurdle, work on it, see how you can reduce time and complexity. CICD should assist you to deliver faster and not reduce your productivity.

Yup, right. It's a win-win situation for both the teams if they work closely enough to share the learnings, and assist each other in their efforts.

Also, CI/CD surely should be helpful. If it's not, probably you shouldn't be using it.
I guess this applies to every framework and technology out there. No one should be forced to do things a certain way just because others are doing it that way, or it is been done that way uptil now. If it fits the role, use it, else, ignore.

You cannot just be a devops engineer as soon as you pass out. It takes experience, production experience and a specific outlook towards release cycles. You will need to experience it on the job. But you can surely start your way into it. Start by automating stuff that you do manually. Start making doing things easier for people around you. Then start making systems reliable and highly available. You'll have to be open to learn new stacks everyday and at times try to resolve one bug for days. Being a devops engineer is kind of a deconstructed sysadmin. Who also has to code at times. Just start thinking of anything you need to do twice has to be automated.

DevOps is a versatile role, that can be a bit tricky. It's more about the setting up the flow of value from idea inception to deploying the code to production(and everything in between like testing, etc).

But start small. Set up a simple deployment workflow. Read about Continuous Integration and Continuous Delivery. Learn about automated testing. Set up your own Jenkins pipeline, connect it with Github or Bitbucket.

A good intro would be reading "DevOps Handbook" or the "Phoneix Project" to understand that DevOps is less of a skillset, and more of a set of ideas and values. Yes, there's a lot of overlap with a sysadmin role, but there's also programming and management involved. It's a wide field so start fiddling with some tools and you'll get to it.

If that makes your deployment lifecycle better and faster. If you automate most of your manual tasks. If you care about your infrastructure. If you care about your code even after it's deployment. And you do this as a team and not just individually, then yes you are a Devops engineer.