Paths that are cloaked will not be pulled into the local workspace during a GET from TFS or VSTS.
Check-ins that contain files only in cloaked folders (in other words, fully cloaked) will not trigger a build, whereas a check-in containing any path that isn't cloaked will trigger a build.

For example, suppose the Project path is $/Example/project/path, and the repository contains the following subfolders:

$/Example/project/path/A
$/Example/project/path/A/1
$/Example/project/path/A/2
$/Example/project/path/B
$/Example/project/path/C
Now, suppose the following paths were entered as Cloaked Paths:
$/Example/project/path/A/2
$/Example/project/path/B
...then the resulting workspace on the Jenkins server would only have the following folders:
$/Example/project/path/A
$/Example/project/path/A/1
$/Example/project/path/C

To continue with the example, the following check-in will not trigger a build, because it only contains changes under cloaked paths:

$/Example/project/path/A/2/alpha.txt
$/Example/project/path/A/2/second.txt
$/Example/project/path/B/bravo.txt
...whereas this check-in will trigger a build, because it contains at least one path that isn't cloaked:
$/Example/project/path/A/1/first.txt
$/Example/project/path/A/2/second.txt
$/Example/project/path/B/bravo.txt