Some implementers take notice of side-channels. An excerpt which is most relevant to your question:
Another important point is that when timing attacks apply, they are all-encompassing: if the context is such that secret information held in a system may leak through external timing measures, then everything the system does may be subject to such leaking. This is not limited to cryptographic algorithms. Research on timing attacks tends to focus on secret keys because keys are high-value targets (a key concentrates a lot of secrecy), and cryptographers talk mostly about cryptography; however, even if all cryptographic algorithms in your system are protected against timing attacks, you are not necessarily out of trouble in that respect.
In your specific scenario, you worry about an attacker who could run his own code on the same hardware as your system, at roughly the same time as you use Shamir's Secret Sharing to split or reassemble shares for your secret data. In that setup, you ignore most "physical" side channels such as power usage, electromagnetic emissions, or noise, since exploitation of these channels requires the attacker to be in the close vicinity of the target hardware. The attacker is supposed to be remote, which limits possible side channels to what can be measured remotely or from attacker's code running on the hardware, i.e. mostly timing. Therefore, I concentrate here on timing attacks, and their countermeasures, dubbed "constant-time crypto". Practical incarnations of that attack scenario would be a multi-user Unix server (attacker is another user with a shell account), or (since this is 2017 and not 1997 any more) a cloud farm that hosts VM, and runs your VM and the attacker's VM on distinct cores of the same physical CPU.
The quoted paragraph above explains that not everything is cryptography. Indeed, you reassemble your data shares in order to have the full data in that computer, presumably in order to do something with that data. If timing attacks apply to the reassembly of shares, they should also apply to whatever you are going to do with that data. Displaying, looking for words, computing values... all of these will leak timing-based information.
In other words, if timing attacks apply to your setup, you are mostly doomed. Some specific usages will be safe: for instance, if the reassembled file is then only sent "as is" to a remote host (through some SSL or similar channel). But, in general, if you are in a timing-attack setup, then you may as well give up; or, more proactively, try to arrange for attackers not being able to run their code on your hardware.
Note that there have been lab demonstrations of cache-timing attacks from external attackers, who do not run their code on the hardware, but exercise an existing service to perform (indirectly) the same cache-measuring actions. Whether such attacks are applicable "in the wild" is still an open question.
To sum up, it may make sense not to fret too much about side-channel leaks on big systems (embedded systems are quite a different story) because such leaks would be part of a much bigger issue that should be addressed holistically.
Of course, one may also point out that it is rather unavoidable that, in a world where everybody can write three lines of code and push it on GitHub, most of that stuff will be, indeed, sloppy.
