Why does chmod 777 -R / leave the system unusable?

There are a couple of reasons.

First in addition to the usual read/write/execute permissions there are some other bits that file permissions contain. Most notably setuid and setgid. When a program with one of these permission bits is set is run it gets the "effective UID" and/or "effective GID" of the program's owner rather than the user that ran it. This allows programs to run with more permissions than the user that ran them. It is used by many crucial system utilities including su and sudo. Your chmod command clears these bits leaving the utilities unusable.

Secondly some programs (notably ssh) do a sanity check on file permissions and refuse to use files with permissions they see as insecure. This reduces the risk of careless admins accidentally leaving security holes but it makes dealing with wiped-out file permissions all the more painful.

A short answer.

Linux system requires specific permissions for certain programs like sudo, etc.

When you run chmod 777 -R / you wipe all permissions and replace them with 777. This makes the system unusable unless you manually restore all the permissions.

In practice it is much faster and easier to re-install.

The problem is that many system programs are designed a way that they do not start if they "do not like" the permissions. This is made for security reasons.

I think it is more important to explain how to handle the system design in paractice than to explain why each program fails to work with wrong permissons.

If you really want all users to have unlimited permissions in Ubuntu, you can add all users to the sudo group instead of changing file and directory permissions. That will have the same effect, but will not ruin the system.

Another way (a very bad one) is to activate root account and allow everyone to login as root.

chmod has subtle nuances.

chmod 0777 behaves differently from chmod u+rwx,g+rwx,o+rwx in that the setuid and setgid are zeroed by the first and preserved by the latter.

That is why the system became unusable. You removed necessary setuid from a few programs.

Here is a list of setuid or setgid files on my Linux Fedora 23 laptop:

[root@fedora23lnvr61]# find / -perm /g+s,u+s
/var/log/journal
/var/log/journal/75e870eb13c74fbf97556a32ecf80ea2
/opt/google/chrome/chrome-sandbox
/usr/bin/rogue
/usr/bin/gnuchess
/usr/bin/locate
/usr/bin/umount
/usr/bin/lbrickbuster2
/usr/bin/gpasswd
/usr/bin/crontab
/usr/bin/fusermount
/usr/bin/su
/usr/bin/at
/usr/bin/newuidmap
/usr/bin/sudo
/usr/bin/pkexec
/usr/bin/mount
/usr/bin/chsh
/usr/bin/newgrp
/usr/bin/passwd
/usr/bin/chage
/usr/bin/chfn
/usr/bin/write
/usr/bin/newgidmap
/usr/sbin/mount.nfs
/usr/sbin/lockdev
/usr/sbin/netreport
/usr/sbin/userhelper
/usr/sbin/usernetctl
/usr/sbin/unix_chkpwd
/usr/sbin/pam_timestamp_check
/usr/libexec/kde4/kdesud
/usr/libexec/kde4/kpac_dhcp_helper
/usr/libexec/dbus-1/dbus-daemon-launch-helper
/usr/libexec/qemu-bridge-helper
/usr/libexec/openssh/ssh-keysign
/usr/libexec/spice-gtk-x86_64/spice-client-glib-usb-acl-helper
/usr/libexec/utempter/utempter
/usr/libexec/abrt-action-install-debuginfo-to-abrt-cache
/usr/libexec/Xorg.wrap
/usr/lib/polkit-1/polkit-agent-helper-1
/usr/lib64/vte-2.90/gnome-pty-helper
/usr/lib64/virtualbox/VBoxSDL
/usr/lib64/virtualbox/VirtualBox
/usr/lib64/virtualbox/VBoxNetNAT
/usr/lib64/virtualbox/VBoxHeadless
/usr/lib64/virtualbox/VBoxNetDHCP
/usr/lib64/virtualbox/VBoxNetAdpCtl
/usr/lib64/virtualbox/VBoxVolInfo
/usr/lib64/vte/gnome-pty-helper
[root@fedora23lnvr61]# 

I removed dozens of noise entries in caches and logs.

Additional to the other replies: you also removed the "sticky bit" from /tmp (which usually has permissions 1777), and this could cause other unexpected problems, as programs would be able to write to or delete each-others' temporary files.

The sticky bit is a special permission which, whilst allowing anyone to create files in /tmp, only allows the person who created it to move or remove it.