These are mutually exclusive.
But I get your sentiment. Password managers are supposed to make handling secure passwords easy and intuitive, but the whole process is way too complicated and unintuitive. However while the UI of password managers may have issues the true culprit lies in something completely different: passwords. The way the world handles passwords is as a direct authentication mechanism for humans. There is no standardization and sites and software usually spend little to no effort on making the process interactable for software like password managers. Unique senseless password requirements are really just the tip of the iceberg there. The whole concept is not designed for software agents. Every site and program does its own thing with password fields, change processes etc. There may be some fractures of standards that are supposed to enable better compatibility with password managers but nothing that gives a comprehensive solution to the root problem or even attempts to address it.
What makes this really bad is that passwords are an exceptionally bad authentication method for humans. Humans suck at passwords. Passwords from ground up exactly strike human weaknesses.
Passwords are an authentication system made for humans but not for computers that humans are extremely bad at handling but computers would be very good at handling.
Actually passwords are also a bad authentication system for computers for various reasons such as only authenticating the party holding the password to the party requesting it but not vise versa while allowing replay attacks.
The real solution to this problem is something like passkeys.
As such a system is not universal yet I understand your desire to try to solve that on the side of the password manager. But just reducing the complexity and magnitude of the process onesidedly at the password manager by just reducing it from the functionality does not solve the problem. Instead the issues just get unaddressed.
For example I do not think that hiding password generation options will solve the problem of inconsistent and really just random password requirements and showing them after that approach failed does not look like a simplification to me.
I do however agree that password manager UIs and functionality need an overhaul and that something like a simple mode would be very helpful. However that simple mode would need to automate a lot of complexity rather than ignoring it for example the default password generation method could use some mode of maximum compatibility with common password requirements while retaining sufficient mathematically provable entropy (e.g. only use a limited set of special symbols but always include at least one of them, a number and capital and lower case letters in the generated password). If that fails the could be a heuristic that tries to find and interpret the error message and adapts to it.
To suggest a simple direct solution to your problem: If your parents are really unable or unwilling to use a password manager no matter what, you should assess the threat model and consider whether a physical password book might be a solution. To add limited protection against an attacker with unauthorized physical access you could make the password out of two parts: the unique part written in the password book and a constant part remembered by your parents. So for example your parents would remember RedGumPaleFrog and the password book would look like
site X: 0I"|t)EBY3b< site Y: ag8q5cVn|t(|
The password for site X would then be 0I"|t)EBY3b<RedGumPaleFrog.
That only is an option if physical intruders are further down on the list of probable threats of course.
This might look far from ideal and even much more cumbersome than a password manager, but if it works better for them that way and makes them actually use that method then it is just a practical solution that adapts to the circumstances and threat model and provides security in these skewed requirements.