At the moment, it's relatively safe. Most ransomware has targeted Windows users, and so far, the ransomware that has targeted Macs has been relatively crude. The latest (very crude) Mac ransomware threat did not destroy Time Machine backups, but was not stopped by FileVault.
In general, the steps you describe in part 2 of your question are unlikely to help protect you; encrypted data is not harder to re-encrypt than unencrypted data.
Vulnerabilities that don't require what you describe in part 1 of your question are rare, but are found from time to time. Mac Ransomware that uses one has yet to be seen. It's likely that Mac Ransomware will slowly get more sophisticated, and careful, savvy users are unlikely to lose their data to ransomware anytime soon. But I can't predict the future. This answer may live on for years and such ransomware is likely to turn up eventually. But the meaning of "careful, savvy user" will likely change over time as well.
At present:
Ransomware will have a relatively hard time deleting or encrypting online Time Machine backups. Even as root/superuser, it's hard to delete Time Machine backups:
sudo rm /Volumes/BK1/Backups.backupdb/Orion/2017-03-18-184155/BOOT/var/du--sortedALLk.13224.bak
Password:
override rw-r--r-- root/wheel for /Volumes/BK1/Backups.backupdb/Orion/2017-03-18-184155/BOOT/var/du--sortedALLk.13224.bak? y
rm: /Volumes/BK1/Backups.backupdb/Orion/2017-03-18-184155/BOOT/var/du--sortedALLk.13224.bak: Operation not permitted
But it's far from an insurmountable problem. I think folks should assume that the additional step that the ransomware would have to go through (which I'm familiar with but choosing not to publicize - I'd rather not help script kiddies) to be able to delete or encrypt TM backups is something most Mac ransomware you're likely to become infected with will be programmed to take.
Time Machine users are encouraged to allow backups to run often, which makes them quite vulnerable to ransomware.
Therefore some backup drives should be connected less often and kept more secure - not fully accessible to the system - specifically to protect from ransomware.
Typically, victims realize they've been infected with ransomware only when the ransomware announces its presence. So it's likely you won't be able to tell that a computer is infected with ransomware before it has a chance to encrypt the data on a frequently or continuously connected external drive. Assuming otherwise is far from a safe assumption. The ransomware threat makes better disaster preparedness, including having more numerous offline physical backups, more important.
At the most basic level, Apple controls the firmware and stores the absolute minimum information needed to present the illusion that an OS is running at the pre-boot log in screen when FileVault is enabled.
This is documented quite extensively by Apple:
Prior to the T2 chip which serves as a sort of trusted module to authenticate if the OS being booted is properly signed / encrypted and/or not tampered with, this pre-boot information can be stored in NVRAM as well as the EFI / recovery HD which don’t get encrypted with a key that needs a user password/passphrase to unlock the main storage.
When you change the background or users that are allowed to unlock FileVault - this cached data is saved outside the encrypted portion of the disk so we are presented with the icons and graphical log in screen. When I see Apple say the startup disk is encrypted, I take that to mean the Macintosh HD logical volume only which stores all user data and all OS but not the firmware and pre-boot data. (except for the T2 chip enabled hardware which are special cases and not the norm yet)
You can confirm this with either commend below based on whether your OS supports APFS and APFS containers which is the new standard for volumes and encryption or HFS+ and Core Storage containers.
diskutil cs list
diskutil apfs list
The other exciting change that’s in progress relating to the T2 chip on the new MacBook Pro and the iMac Pro is that it can enforce encryption to the internal storage whether or not anyone takes the second step of FileVault encryption. Specifically, it will generate an encryption key and start encrypting all data before the user account is even created. An SSD from any of these will not be readable if taken to another computer whether that computer has a T2 chip or not. The keys needed to decrypt the entire drive are stored solely in the Secure Enclave.
Best Answer
APFS encryption is done with the AES encryption algorithm in XTS mode with a 128 bit keylength. This is the same algorithm, mode and keylength used by earlier versions of macOS too (i.e. with HFS+ file systems).
As you mention Windows BitLocker, this is actually the same method and strength that Windows has recently started using in the newer versions of Windows 10.
Regarding your other questions about guest users and account passwords - this really has nothing to do with APFS encryption. This is instead handled by a layer above called File Vault 2.
File Vault 2 with APFS is really the same as with HFS+ with the one difference that APFS has built-in encryption support (i.e. the AES-XTS-128 for encrypting the data) where HFS+ needs encryption added as layer on top of the file systems (i.e. via Core Storage). In practice there's no real difference for most end-users.
In any case, all the key handling that makes full disk encryption work for the end-user to handle such things as booting from an encrypted drive, user accounts, guests, recovery keys, etc. are all handled by File Vault 2 - which is seperate from the file system itself.