No, it does not. EFS is transparent encryption (and decryption). If you try to read the file - possibly to upload it to a server, but also possibly just to read it in Notepad - and you're running as a user with access to the key, then the OS will obligingly decrypt the file contents for you as part of the
ReadFile system call.
You say "simply uploading a file" but that's not really a thing. You usually only upload file data to a new file (or to something else, like an S3 bucket or in-memory analyzer or database or whatever). If the destination is in fact a new file, it can (totally optionally) have the same name and other metadata (timestamps, etc.) as the original file, but for that to happen the uploading utility would have to deliberately send that metadata along because it's part of the file system and you are not uploading a file system object, you're uploading a stream of bytes (which are typically just the file contents).
There exist networked file systems that support transferring data as logical files rather than just as blobs of bytes. Windows even supports a few of them out of the box. Of those, though, only Windows Networking is likely to have any support for maintaining EFS across a transfer. Additionally, "copying" or "moving" a file to any of those from an internal drive is - just like moving a file from a flashdrive to a HDD - just automating the "tell destination file system to create a file with this metadata, send over the contents as binary blob" process. The fact that Windows supports recognizing when a destination file system supports encryption and transferring the data encrypted (rather than transferring the plaintext) is cool, but it only works if the OS drivers are doing the transfer. If it's being transferred by the extremely vast majority of user-mode software - e.g. if you use a web browser or FTP client (even one built into Windows!) to transfer "a file" between two file systems (or even between two processes on the same machine!) - the data will be decrypted before being exposed to the process, and only re-encrypted (by EFS) at the destination if the destination process tries to write the received data to an EFS file.
Since ransomware has absolutely no reason to jump through the hoops necessary to read the encrypted data directly off the drive (skipping the transparent decryption on read), and since it almost certainly isn't using SMB to transfer the files (it's not a great idea to expose SMB to the internet at all, its security is... outdated), the file contents will surely be decrypted by the OS before the malware uploads them.