As I understand it, it's a holdover from NextStep (which OS X is based on), and NextStep did it to support NetBooting. The idea was that you could boot from a network-hosted volume (probably read-only, and certainly shared with other computers), and early in the boot process mount a local (writable) volume on /private; as g mentioned, this allowed runtime-modification of /var and /tmp, as well as per-computer settings in /etc.
This isn't needed anymore, as Apple's current NetBoot system uses a shadow disk image to store changes anywhere on the boot volume. But some programs/docs/etc now assume the files live under /private, so it'd be too much trouble to switch them back...
Update: since I wrote this, Apple has stopped supporting NetBoot, so the original purpose of /private is even more obsolete. However, in macOS Catalina (version 10.15), they've added a new volume split. In this case it's for security rather than to support NetBoot, but it works in a fairly similar way.
Catalina's system volume is mounted read-only, with a read-write volume mounted at /System/Library/Data (analogous to the old system that mounted a RW volume at /private), and "firmlinks" making parts of the RW volume appear at their usual locations in the filesystem (again, analogous to the symbolic links that make parts of /private appear at their usual locations). For example, /Users is now a firmlink to /System/Library/Data/Users. The Eclectic Light Company has a good summary.
Catalina also still has the symbolic links to /private; thus, when you access /etc on Catalina, it follows the symlink to /private/etc, and then the firmlink to /System/Library/Data/private/etc
Changing the permissions on /private/etc/sudoers is definitely a no-no. The sudo command will fail to work if that file's permissions are not 0440 as you are noticing. This is a security measure -- the command distrusts any permission setting that is less restrictive than 0440 as it allows for potential tampering with sudo permissions on the box.
Normally you'd boot in to single user mode to fix this problem. This lets you log in with elevated privledges so you can do a:
chmod 440 /private/etc/sudoers
and get your sudo command back.
But I found this article that had an alternative that doesn't require a reboot and works if your account has Administrator level access. I haven't tried it, but it seems sound.
Open a Finder window a hit Shift-Command-G to get the "Go To" dialog. Enter /private/etc in the dialog and hit the Go button.
Find the sudoers file in the Finder window, select it and press Command-I to open the information window for the file and change the permissions on the file so they match:
Close the information window and you should be back in business.
All this being said: I would strongly encourage you to rethink changing the permissions of everything under /private/etc to be world readable. This poses a serious security risk (as seen from the way sudo locks you out when you make /private/etc/sudoers world readable) to your machine. Maybe there's another Ask Different question here that'll help you solve a problem you think you're solving by making these unsafe changes?
Best Answer
Maybe resetting the permissions on a user's home directory helps: This is easily accomplished by resetting ACLs on the desired home directly by using the Reset Password Utility in the Recovery Partition: 1 Restart your computer from the recovery partition (restart while holding CMD+R). 2 Open Disk Utility and run a permissions repair on your startup volume. After this is complete, close Disk Utility (doing this just for good measure). 3 Open Terminal from the Utilities menu. Type in resetpassword and select your user account (NOT System Administrator/root) from the drop down menu. 4 Click the Reset Button at the bottom of the window in the Reset home folder permissions and ACLs section. 5 Quit the Password Utility and go back to the main recovery screen. 6 On your keyboard, hit CMD+Q and restart your computer. It's very important that you don't hold down the power button to exit the recovery session, or the ACL reset won't occur.