EAV schemas are problematic, and fortunately we have "EAV" as the name for that problem.
The Normal Forms
The "normal forms" are not hugely inconsistent with good practical design. The basic principle of the NFs is simply that you don't store the same data twice.
Duplicates are costly with storage, especially at 1970s prices when the lower NFs were first described, and still even today when typical business volumes are involved.
Duplicates are also costly with computer power and affect performance adversely. For reads it leads to lower consolidation and locality (of all data taken as a whole), and for updates it increases the variety of places that need to be visited in storage and extends transactional locking times.
And it is costly with staff labour, in that duplicates add unnecessarily to the overall number of fields within the system which staff have to handle and remain abreast of.
Also, the implicit context for academic thinking on NFs are OLTP loads. That is the main application for which database engines are designed and for which this entire area of thinking is adapted. That context must be borne in mind, and if you step radically outside of it then things will make less sense.
New developers struggle with applying normal forms, and the reasons are several.
Denormalisation performs better
Firstly, there are sometimes denormalised forms that perform better in practice.
One reason is because for certain sets of algorithms and execution schedules, the duplicates can enable increased locality and concurrency of access to storage (when we initially said the problem with duplicates was that it reduced these things). That is, the duplicates might cause inefficiency with an arbitrary set of algorithms and schedules, but they cause better efficiency with the algorithms and schedules that actually apply to that application.
Another reason is that real-world SQL database engines suffer from conceptual and architectural constraints, or infelicities if not downright limitations, that don't exist in theory. For example, cross-table indexes (by which the records in one table, would be identified or filtered by reference to a field in another) either don't exist in many engines, or if they do, they're a different animal than ordinary same-table indexes.
Duplicate or not
Secondly, there can be confusion and ambiguity as to whether something actually is a "duplicate" or not. Most commonly, this arises when a developer fails to account for the importance of recording and retaining data at a point in time. The data values may be the same across a time range, but each instance is intended to record the reassertion of a fact at the time that record is made, and not all such records are made at once but accumulate over time, and what gets recorded is therefore not "duplicate" data within the meaning of NF.
To give a simple example, if you record you have 50 children turn up to a school club today, and 50 yesterday, the number 50 is not duplicate data just because it happens to be the same number on two consecutive days, but a completely independent fact about how many turned up on each day.
Developer ease
Thirdly, NFs (especially the higher ones) can be very difficult for developers as mere mortals to use and handle. In other words, less normal forms can be more straightforward to design and interpret without causing any performance problems, and the theoretical flaws or limitations this introduces is not found to be important relative to the importance of saving developer labour and easing the complexity of design and supervision.
This is why the vast majority of database designs do not even approach the higher NFs, because it doesn't solve a real performance problem like the lower ones tend to, and it causes too much difficulty for the people involved.
Business records
Another thing that many younger developers lack is a broad familiarity with business administration and practical record-keeping in business, and standard terminology, concepts, patterns of activity, and standard "forms" of business records.
I'm using "form" here in the conventional sense of "a pre-printed paper sheet whose format accommodates certain data, and is filled-in upon the happening of some event", or its computerised analogy.
Many business records are mandated by law to be stored in a certain way - that is, containing certain data and occuring upon a specific event - or they have some kind of legal or forensic function (including the fact that duplicate data can make accidental damage less likely to occur without it being apparent that it has occurred).
Even when not everything is dictated by law, standard business forms and the practices which surround them, are highly adapted to their function, in ways that can't just be casually imagined from a starting point of ignorance, and which sometimes require deep analysis and complicated scenarios to be set up to demonstrate the importance of doing things in a particular way (or to demonstrate the folly of an alternative proposal from someone who is not remotely abreast of what functions and constraints are in play).
Good database design
In summary, "good database design" is not reducible to a few keywords or slavish application of any simple criteria.
Even very well-known concepts like the Normal Forms, require intelligent application and professional judgment and experience of the business area to which the computer is applied, and adjustment to testing and performance of a particular database design in practice.
Almost anyone proficient in database design is not friendly to the jargon and dictums that arise from the Object-oriented Programming space, because the conceptualisations are different, arguably unsound, and the practices there lead to excessive complexity and computational inefficiency relative to the functionality achieved. So asking how those in database work can be more like the OOP crowd with their keywords, is not necessarily regarded by database practitioners as an exemplar to emulate.
As I say, good database design arises largely from a deep understanding of how a particular organisation or business is administered (such as a government department, bank, or insurer, as you mention your experience includes), or how businesses are administered in general, and creating a good correspondence between that thing and the database design.
