A consultant's most important responsibility (other than stealing your watch, telling you what time it is, and sending you a bill) is to give opinionated advice where it is held.
Most of the time this advice should fall into the "this is my opinion, but going against it is perfectly valid" category. Advice which matches the only reasonable action isn't advice at all, it's an observation.
"Don't use DevOps Engineer as a job title" checks both of those boxes.
I originally wrote my definition of DevOps in less than 30 minutes while waiting for a plane. I had just come from an event where questions afterwards made it clear that I needed to clarify what I mean when I use the word. I didn't publish it for weeks out of fear of alienating people, or worse, gatekeeping new folks who are quite reasonably responding to the market.
I'm sure that people in an audience during a talk, watching a video online, or reading a blog post feel personally attacked or judged when I say this and it haunts me.
Do the right thing for your career.
If you're trying to find a job in automation or platforms the majority of job listings may well be looking for this as a job title. Search for it.
Recruiters will be searching for people with this title on websites like LinkedIn. Add it to your profile. Also add a description of your responsibilities that demonstrates you understand this is not a sole contributor role (if you agree that it's not).
After you get the job, try to influence your organization into understanding that DevOps is a way of working. Just like someone with a DBA background will most likely be more knowledgeable about the database, you may be more knowledgeable about the platform or automation, but you both should contribute to the team's shared understanding. This will make both you and the organization more effective.
When filling roles which require automation or platform expertise, feel free to use and advertise the title DevOps Engineer. Qualified candidates will be searching for it. Make it clear in the job description that while they may be a subject matter expert, a large part of their responsibility will be creating and maintaining a shared understanding of areas.
I still recommend that you avoid actually giving people the title of DevOps Engineer. Not because I don't like it, but because it implies individual ownership. If your people believe (even subconsciously) a part of your system is solely someone else's responsibility they won't learn about it. This is not because they are lazy, it is because they are focused.
When people with more experience writing code understand the deployment platforms where that code will be running and the automation that will get it there they will create better code. When people with more experience in platforms and automation understand the code that is being developed they will create better platforms and automation.
I said above that a consultant's most important responsibility is to give opinionated advice. The second most important is to understand that the advice is just one data point, and the person receiving it should receive your full support for choosing not to follow it.