As a user there are two rules to password use:
1). Never re-use the same password with different entities (e.g., don't use the same password at your online bank as a free webforum set up by some anonymous individual). Any site potentially logs passwords in plaintext (even passwords for other sites accidentally typed) and potentially could use those passwords to attack users on other sites. .
2). Pick high-entropy passwords/passphrases (preferably randomly generated and only slightly modified) that will not be found in a dictionary attack or in any list of common passwords.
A system where users locally store an passphrase-protected encrypted list of randomly generated passwords synced between all your computers is a great solution, but you can't expect most users to be doing this.
As a developer setting password rules for a system its a balancing act. Stricter rules generally mean a more difficult user experience (UX). If your rules are especially strict, users will circumvent your rules somehow. They'll write it down by their computer, save it in plain-text on their desktop, or stop using your service, or complain incessantly to higher-ups, or use the password reset mechanism every time to login (which may end up being a much weaker link). Maybe you require a number in their password, they take a common dictionary word and just append a 1 to the end. You require passwords to be changed every three months and not reused, and the end user rotates their password to be
Conversely not having any rules means you will find many idiot users who will choose a password that's in a list of the top 100/1000 password lists.
Custom rules are nice, as you can set a bare minimum for length/complexity and additionally may prevent password reuse if your rules are quite particular (e.g., no special symbols; but at least two numbers and one upper/lowercase letters). However, you should make sure your custom rules do not exclude strong passphrases, which are a good way to achieve memorable high entropy passwords. Also, invalidating common, weak passwords may help secure your application. E.g., if you don't allow a user to set a password that is a dictionary word plus a number at the end, or a password from a common password list, that may strengthen security. (Though again an attacker can use that information to know what passwords not to try; and your users may find the bare minimum that passes your rules).
But to answer your question, the entropy of an 8-character password consisting of any number of digits, upper and lower case letters randomly chosen is lg(628) ~ 47.6 bits (let's ignore symbols). The entropy of an 8-character password where exactly three letters are digits is 44.3 bits ~ lg (56 * 525 103) (56 = 8 choose 3; the number of combinations of three digits chosen from 8 positions), so its slightly weaker. If you relax the condition to require it to be 8 characters and have three or more digits; then its still only 44.6 bits. So requiring
d digits in an
N symbol long password slightly weakens it compared to allowing any symbol, but only by a couple of bits of entropy. Though alternatively if you compare a 7 digit password without no number requirement lg(627) ~ 41.7 bits and add a forced choice of digit inserted into space at random; the new password is 80 times (6.3 bits) stronger (ten choices for digit; 8 choices for location of forced digit).