There are really 2 types of companies when it comes to DevOps: those companies that and gender a culture of DevOps with their Dev and Ops teams, and those companies which hire a dedicated DevOps team. In my experience people who go to these conferences are almost always from companies of the latter type. It is often argued that the only true DevOps way is that of the former type, but in my experience the company's that talk about DevOps are more often of the 2nd type as that setup in a company is much more common.
It is like REST API's. Most folks that write REST API's are really writing HTTP RPC API's, only a few are doing true REST, but nobody cares; it does the job.
On point, I will just add one thing, the split is not really binary. There is a continuum depending on leadership and teams.
Most companies start as latter either because of historical reasons. i.e they already had a dedicated systems/ops team or because a significant majority of engineers are not interested in doing cross functional/vertical product engineering.
I have experienced two such efforts. One where the transition had varying degrees of buy in from whole eng org and happened slowly but successfully, another org where developers kept (indirectly) refusing to own up their systems past build phase and engaged in unproductive turf wars.
As a development engineer nothing is sadder than seeing a fellow dev engineer not giving a damn about either larger picture (why our product exists/why our users's lives are going to be better because of the product) or about how's the system behaving outside of their little bubble of local machine and jenkins.
PS: I do acknowledge that different people have different motivations depending on what's going on in their personal live.
It is like REST API's. Most folks that write REST API's are really writing HTTP RPC API's, only a few are doing true REST, but nobody cares; it does the job.