What does Windows's built-in encryption do, if I can seemingly always read my encrypted files?
Windows built-in encryption is done transparently at the filesystem level. The encryption key is stored in your account profile encrypted with your login password (this is why there's the warning when you change your password). So logging in unlocks the key, which then makes your encrypted files available.
Since the encryption and decryption is done transparently by NTFS, you don't ever actually see the ciphertext. If NTFS doesn't have the decryption key, it simply won't let you read the file. You can get to the ciphertext by reading the partition data raw, but there's no real advantage to doing that. The file can only be decrypted using the key I mentioned, which you never actually see.
Windows lets you back up your encryption key, where you export the key encrypted with another chosen password. This is useful if you ever put the disk into a different computer or reinstall Windows. But not really useful otherwise.
Since the encryption is tied to the filesystem, it's not designed for sharing encrypted data. Instead, you're protecting the files where they sit against anyone else who gets their hands on your computer.
If you want to create an encrypted container for transferring files to someone else, I'd recommend a compression tool that supports strong encryption. 7-zip is a great choice.
The encryption key is tied to your account and unlocked when you enter your account's password. As far as I know — but I'm not a Windows expert — what “unlocking” means depends on the version of Windows and whether a TPM is available, but the idea is that the encryption key cannot be retrieved without guessing your password (and, with a TPM, cannot be retrieved on a different machine even with your password).
Access to encrypted files is transparent in the operating system. When you try to read from an encrypted file, it is decrypted on the fly (and conversely encrypted when you write) by the operating system, so that applications don't need to be aware that some files are encrypted.
When you copy the file to another computer, the content of the file is copied. It would be pointless to copy the ciphertext.
You could observe the encryption by setting the file's permissions so that another account can read it, and trying to access it through the other account. You could observe the encryption by mounting the disk on another machine, or booting another operating system (e.g. a live Linux system). In these cases, the key would not be available, so you would not be able to access the data.
The security property brought by encryption is that if someone gets hold of your computer (or more precisely to your computer's disk) while you are not logged in, they won't be able to access your data (assuming they fail to guess your password).
It's extremely useful for enterprise uses like "Roaming Profiles" where data is copied from a server to the local workstation when you log in. Every different user logging in would have their own profile directory with their own files.
The file level encryption means that even if somebody captures the disk from the machine, the contents of the profile directories of all the users who've logged on to that machine contain nothing but encrypted data.
The enterprise encryption scheme (with Active Directory) also has features like "Key Recovery" which allows management to read your files if you decide to not come back into work, or if you forget your password and need a new one set.
When you use this outside an enterprise, it's not a great system. The Windows SAM database still contains a hash of your password for logins. This is a weak point in that the password needs to be protected against offline attacks. I.e., brute forcing the SAM DB
There are ways around that by encrypting the SAM DB, but at this point, you're a lot better off using something like TrueCrypt, Bitlocker or some other whole disk encryption scheme. File level encryption is interesting in Windows, but I haven't found a use for it outside of enterprise environments.