Your biggest clue to purpose and location is in the "big type", i.e., the names of the respective hives: HKLM and HKCU
File associations are set in both hives and have two different purposes:
As the name implies, HKCU registry entries set file associations for the CURRENT USER and override the corresponding file type settings in HKLM.
HKLM sets file associations for the LOCAL MACHINE, i.e, for ALL USERS of the machine (unless overridden by HKCU entries). (For Win98, HKCR was just a shorthand alias for HKLM\Software\Classes. They were not separate or different hives. However, this changed for Win XP and is no longer true. HKCR is now a virtual hive that is the result of merging the HKLM\Software\Classes\, HKCU\Software\Classes\, and HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts keys with the HKCU info taking precedence.)
This two step system facilitates not only one-to-one but many-to-one and one-to-many file association schemes. For example, .htm, .html and .shtml filetypes could all be set to ProgID=htmlfile which in turn could define a single browser. OTOH, the entries could contain OpenWithList or OpenWithProgID subkeys with multiple entries to open a file from a list of multiple browsers, editors or other apps.
Both HKLM\Software\Classes\ and HKCU\Software\Classes operate the same way (one just takes precedence over the other).
In the simplest form there is a registry key for a file extension (e.g., HKCR.txt) whose default value is the corresponding ProgID (e.g, txtfile). In addition to, or instead of, the default value, there may be additional ProgID names listed for the "OpenWithProgID" subkey (e.g., txtfile and htmlfile), and/or additional application names appearing as subkeys under "OpenWithList" (e.g., Notepad++.exe, Opera.exe, Firefox.exe).
Each ProgID is defined in another key within HKCR (e.g., HKCR\txtfile). This key contains subkeys to tell windows which icon to use and how to open, print, printto, etc the associated file (e.,g, HKCR\txtfile\shell\open\command). Similarly, each application name is defined as a subkey under HKCR\Applications (e.g., HKEY_CLASSES_ROOT\Applications\Firefox.exe\shell\open\command).
In addition to the HKCU\Software\Classes key, user account file associations are found in the HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts key. These entries are not for just Windows Explorer as has been suggested but are an addition source of user account file association overrides. The entries are created by the file association tools in explorer (Explorer \ Tools \ Folder Options \ File Types) and contain an OpenWithList and/or an OpenwithProgID subkey for each listed file extension.
To determine a file association, Windows looks first at the HKCU entries for a corresponding file extension. Only if one is not found do the HKLM entries come into play. (Note: I have not tested which takes precedence - the HKCU\Software\Classes or HKCU\MIcrosoft\Windows\CurrentVersion\Explorer\FileExts but I suspect it would be the FileExts key). Likewise, if a referenced ProgID or application name is not found in HKCU, the HKLM entries are searched. (Note that \Applications\ entries are just arbitrary name - even though they typically are identical to the actual on disk exe file name.)
So to define a file association for a specific user account, create entries in the HKCU hive. To define an association for all users, create entries in the HKLM hive (HKCR) and delete all references in the HKCU hive to that file type. Obviously you need the appropriate access rights to the registry keys.
I don't use the assoc and ftype tools as I prefer using RegEdit in either interactive or batch mode but from other comments it appears that they only operate on the HKLM hive and are useless for clearing/setting HKCU keys. Take some time and browse the abovementioned keys with RegEdit to see more examples.