Since it was my post you are linking to, I feel obliged to try to explain 
Unreal has several layers over how it works with regards to assets, what actually gets worked on inside the editor. When you import a file, be it a Datasmith file or texture, as you are aware it makes it’s own ‘Unrealified’ version as a .uasset file, (or multiple files, in the case of most .udatasmith imports). The originating file then becomes somewhat superfluous; it can be removed, deleted, changed etc. but it has no impact on the version in Unreal. The sole concession to this, is that assets inside Unreal get a field with the path to where they came from, so you can reimport to update them as necessary.
But it does not stop there. In a similar vein to, say, your scratch disk in Photoshop, Unreal also has a Derived Data Cache that contains the data you are actually working on at a given point in the editor; this is often not a small chunk of disk space. When you first import an asset, or open a project, Unreal has to build this Derived Data Cache (DDC), which is why it can take a while to open a project for the first time. But it is made entirely of derived data that can be regenerated whenever is needed, as so it’s not the most crucial thing in the world to protect. Why do I mention this? I’ll get to that in a moment…
Now, there are a number of ways bigger groups work collaboratively on a game or project, but usually the individual texture files and similar non-code related assets, while being worked on, don’t actually live in or around the Unreal project directory. They will be elsewhere, under their own system for versioning or snapshotting or the rest of it as needed. That also will often involve a traditional file server, a mapped network drive, and similar. But they don’t directly interact with the Unreal project beyond being imported; it is the imported .uasset file that is checked in, not the original .psd file. That way they are saved, archived, sent off for outside work etc. without having any impact on the Unreal project.
(It is true that there are some that do put it under version control with the Unreal project, but the important takeaway is that they do not have to. Depends a lot on how often the files are iterated over).
Given it’s rather direct (and intermediary ) usage in the Unreal workflow, I can certain see why it might get a bit upset with .udatasmith files living on the network vs locally for import, (In the same way that building the project can have the occasional issue doing so off the network vs local), but re-tessellating does not in fact look back to the .udatasmith file at all. (https://docs.unrealengine.com/en-US/Studio/Datasmith/SoftwareInteropGuides/CAD/Retessellation/index.html](https://docs.unrealengine.com/en-US/Studio/Datasmith/SoftwareInteropGuides/CAD/Retessellation/index.html) ) As far as Unreal goes, the only time it will ever look back to this file, to my understanding, is to reimport. As such, you can happily toss the .udatasmith file away after that if you wish; if something happens to the .uasset files, you would usually reload from the checked in copy in your version control, rather than from the datasmith file, (assuming the import was OK in the first place).
If you need to preserve specific versions of the .udatasmith data, (for instance, as a snapshot to show exactly what the state of the files where when you sent them to a supplier), then that of course is a separate thing, but it is outside the Unreal project workflow: it can live wherever is most appropriate for the use it is being put to. But there aren’t many reasons to keep them around other than that; like the Derived Data Cache, it’s assumed that if something very odd happens, you can regenerate them from the source. This is to say nothing of incompatibility between Datasmith versions…
Now, you can have your project’s Derived Data Cache live on a network share; that way, only one person needs to do the crunching of the assets, and that first slow load up, and everyone can benefit. This is especially handy when there are lots of imports involved; just be aware that this can also be a not-small amount of data, as well as the fact that over a network is not as fast as locally. It’s also not advised to snapshot, backup, or version control this cache either.