That's fair. In that spectrum I'd rank folks that see agile as but one tool in the shed higher than those that agree it's _the_ way to execute projects.
Being a developer without a good Engineering Manager is a futile exercise in my experience. Software developers deliver quality work and solve problems efficiently as a matter course. If not, they should be let go to work someplace else, potentially outside the software trade. Saying those skills are exclusive to followers of the agile manifesto is silly. Find a good manager that brings you opportunities and respects your expertise. If your manager hasn't put you in a place to be the rock star in the last year or so you need to move on or accept you aren't "all that".
My opinion is based on being a software engineer (junior through principal) at small, medium, and fortune 100 companies. I also have years of experience as an engineering manager.
The pure, normalized models weren't performant enough so you are correct - the design wasn't all roses in the SQL systems. We had largely flattened down some table groups to be able to get data fast enough. But when you hit that point you may have outgrown RDBMS
I'm not saying you can't get one to run fast enough but the ROI starts to decline significantly.
This seems contrary to what I have learned in my career as an application developer on data heavy platforms. Namely the first section that concludes:
> Having stressed the importance of good database design...
I'm not in agreement with the author's concept of good design. I don't want other "doors" to edit the data that bypass the application logic. That's the mess SQL enables for DBAs and scripts that think it's okay to change data without executing business logic.
I think it's better to accept your data and application layers are coupled and plan to evolve and refactor them together rather than teach your database to defend itself from the evil business logic in applications.
I also don't think this dictates relational DBs vs nosql. Your data model is probably relational but how you choose to store and access the data depends more on what use cases you are trying to enable.