I experience this more the other way around: one cannot delete folders behind EP's back while it is running, even when it seems to be focusing on other folders/accounts. This is not a problem. In other words, the only process that is "supposed to be" locking that folder is EP itself. In that case, EP is the (only) process that needs to close its files / release its locks and delete the folder.Removing folders ... may not be successful if they are locked by the filesystem
Okay now, this may be part of the problem. TB-style email clients before the re-write behave multi-threaded-ly; this is why they are wonderfully responsive, and quite moreso than after the re-write. It's easy to imagine a long-lived / cached previous file-access to persist as "open" until a delete-request made by [Remove Account]. If "another thread" still has a file open then the OS will not delete the folder at that time. If you close the client then sometimes the lock is released and the delayed delete proceeds, but sometimes not. In that case the folder may have some files deleted and some orphaned - either way, it's not in a normal state. When re-creating the account, you may get filename collisions or other weirdness from the leftover files. That's a major reason why manually deleting the folder after [Remove Account] is necessary.
For background, when creating an account I specifically set the mail-folder name, and discard the auto-generated folder. Yes this is inconvenient because it requires a restart, but it's worthwhile later for manual account maintenance etc.