Q:

Password required special char vs Password optional special char

Why is it considered more secure when a password is required to have a special char, upper and lower case letters as-well as numbers? 
Wouldn't it be more secure to allow instead of require these chars? 
Let's say someone wants to break the password, wouldn't it be easier for them if they already knew that that password contains at least 1 special char, 1 upper and lowercase letter and 1 number, because it was required. Instead of the possibility for the password to contain these chars if it was allowed instead of required?

A:

It considered secured, from several attacks like dictionary attacks. Since the dictionary attack comes from the wordlist with common words. It's better to require these rules in front-end and backend with validation if the password meets the standards.
In development, you can use OWASP ASVS located here: https://github.com/OWASP/ASVS/blob/master/4.0/en/0x11-V2-Authentication.md
There's a checklist like:

Verify that user set passwords are at least 12 characters in length.
Verify that a password strength meter is provided to help users set a stronger password.

If you follow some standards like OWASP, securing your authentication will be good.

A:

Wouldn't it be more secure to allow instead of require these chars?
Yes and no.
No: As Francis Al Victoriano said it is useful to counter dictionary attacks.
Yes: In a perfect world you should not have to require anything except that the password is not blank. This way, as you said, attackers would not have any hint about what passwords could contain and would not even know at which length they should start a brute-force.
But in this perfect world your users know what they are doing, they know what a strong password is and use one for every application. Sadly in the real world you should never trust the user so you have to ensure they choose a password that is not "too weak".
So, should we force the user to have multiple charsets in his password ?
Some say we should because if we don't the user will choose a weak password like a dictionary word.
Some say we should not (like NIST) because:

The more restrictions you add to your password policy, the more the user will be annoyed by it (he is already annoyed by the fact that he has to use a password) and the more he will try to bypass it and most probably weaken his password in the process (e.g. your super mega complex password will end on a post-it because the user is unable to remember it).
Speaking of bypass, typical password policy is 8 characters min, at least one uppercase, one lowercase, one digit and one special character. Here you go: P@ssw0rd. Let's check if Have I Been Pwned thinks it is a good password, spoiler alert: no.
It prevents users from choosing a passphrase.

My take on the matter is to follow NIST guidelines:

Min length of 12 characters
Password strength meter based on an up-to-date list of leaked passwords (like HIBP) and an offline strength estimator (like zxcvbn) to help users avoid weak passwords
(optional) Server-side password strength validation (based on the two components of step 2) if you want to ensure your user is choosing a strong password and you do not want him to or cannot allow him to ignore the password strength meter feedback.

