Drive by architects don't read books. They read AWS's latest product brochure and think "yes".
The majority of Architects I've brushed against in the last decade have been exclusively an additional marketing force for AWS with very little ability to objectively reason from first principles or assist with knowledge of anything outside of the AWS ecosystem.
These are the first principles in question, now from there your architecture is mostly determined, you can fall back on known patterns and decades of research. The axioms are the architecture.
"First principles" in this context is not just reaching for the nearest/newest AWS service that seems to do what you want. ie. if you want a webserver, don't just run magic lambdas that abstract everything away from you, go and provision a vps and install your dependencies on it so you fully understand and control how the stack works.
None of the 12 engineers at my current company had written a test that actually wrote rows to a database when I arrived, they didn't know how. In fact none of them knew anything about how to run our databases on their own dev machines at all, they all shared one RDS PG instance.
Again, "first principles" here is: running a process, connecting to a service, asserting the whole thing did what you expected. To do that effectively you have to actually control the whole system, and to do that you have to know how the whole system works together. A lot of developers now just delegate the provisioning and maintenance of everything to a provider, even in development setups.
First principles to me is the basic foundations of an idea.
Abstractions are used but; any given abstraction is not owned by a single vendor and are based on agreed upon standardised abstractions as they relate to to operating systems and databases etc.
The bad ones took what they read as gospel and the good ones took what they read in context.