I’m new to version control with TFVC in Visual Studio 2019 and I’m not able to understand what the “Check Out” option does. I couldn’t find a true definition and real use case for it. In particular, I’m working in a team. When I compile a certain project, I need to copy two dll files created by the previous build process inside two folders related to different projects, replacing their old versions of the dll files. Now, after building the project, they told me I have to check out the old dll files selecting them and clicking Check Out from Source Control Explorer and I just have to copy the new dll files, replacing the old ones with a simple “copy and paste” inside my local workspace. Why do I need to check out those files? Why can’t I just open my local workspace and replace the old dll files with a “copy and paste” directly?
I don't really understand your team's workflow. Let me throw a couple of ideas for you to figure out if your current workflow is the most appropiate or not.
TFVC is a centralized version control. Meaning that there is a "single source of truth" which lies on the server side.
For this to be truth, any developer that needs to work on some file under the source control sight, needs to take a decission on how to work with shared files. Simplifying things a little you have here a workflow - not the best, neither the only one - that may help you to figure out what to "check out" a file means.
If you follow this simple workflow you'll find that whenever you get the latest version of the code you'll may find that someone else has made changes in a piece of code you are working on. Meaning that you need to merge those changes. At the same time, and for the same reason, whenever you "check in" code into the server, you may find some differences between server's version and your's, which may lead to new merging activities again. In such scenario, centralized version control allows you to "check out" a file. Meaning that you "own" that file and no one else can merge their changes in the central repository until you check in your changes. This may be fine in some scenarios, but if you're used to distributed version control systems (like Git) may sound a little weird to you.
Going back to your example. It was a common practice (but not a good practice) to check in dlls in TFVC for the developers to get those dlls from the centralized repository. You'll be probably checking out the dlls because you're going to compile the code and you'll have the "latest version". This may not be truth depending on the way your Team works. Nowadays I'd recommend to set up a different approach (like storing them in some package manager) if you need to share shared dlls among your Team.