Here's my take on it.
When the customer gives you grief about normalization (or even using the WORD normalization), your correct response is "You hired me to do this because this is something you couldn't do and I could." You can supplement this by explaining that normalized data gives you a better foundation on which to base searches and explorations of relationships between data elements. It also makes it easier for future additions in a way that minimizes physical growth of databases to push back the point of needing to upgrade the data engine you use for SQL operations. So it lengthens the lifetime of the current investment.
Then, you have either an employee relationship or a contract relationship. In either case, you have a fiduciary responsibility to use industry-best practices in what you do for the boss. I.e. the boss didn't hire you to slack off when doing his/her job. Like the GIECO commercial, you didn't hire a doctor who was "O.K." You wanted someone who was GOOD at doctoring. See also:
https://www.youtube.com/watch?v=1YT3erQZoq4
Even if you can't explain the "how" to the bosses 'cause it is beyond them, you can explain the "why" of it all. It is done to minimize excessive repetition of data and to isolate relationships to other essential parts of the DB. Normalization distills and focuses on how things fit together, but it does so in an organized and predictable way - which makes subsequent programming costs lower.
This next quote won't mean anything to them, perhaps, but it should be mentioned. Niklaus Wirth, the Swiss computer scientist who devised the PASCAL language (among several others), is often quoted as saying that 80% of all program failures are cause by poor data design (though I can't find the source of the quote at the moment so have to paraphrase). You can look him up with your favorite search engine to get over 30 quotes including some comments on complexity. Wirth is a firm believer in the KISS principle - Keep It Simple, Stupid!
As to the 1-1 relationship: With the Navy we had a few special cases where 1-1 made sense. In each case, we were using the ORACLE protection scheme (which, in Windows would have been called "permissions scheme") to prevent casual viewers from seeing data covered by Privacy Act or HIPAA rules. We also had one other case - where we had 1-1 data regarding a person but it was very large, rarely used, and was likely to cause a record-length issue if retained with the rest of the main record. But if we kept it as a separate table and treated the data as two records most of the time (one main, one supplement), we could manage it reasonably well. Can't tell you what was in it because I knew of its existence but as the Sys Admin rather than the DBA in that particular system, I never had to actually work with it. The only time I ever actually DID deal with it was when I wrote some fancy code to help convert data from ShareBase format to ORACLE format when we were converting. (FYI, ShareBase went out of business but some of their engineers banded together to form SyBase.)