Yes, usually we do ignore min_cap violations but that is because we don't get it mostly. 9/10 chances it happens due to bad library characterization, if the library min_cap is very low then you are likely to see a lot of them.
Why it is bad is because you might have to add lots of buffers/inverters and that would increase the gate count.
You can talk to your cad/library team, if they can provide a better characterized library you can simply do set_min_cap (expected value provided by lib team) and let the tool optimize, but if it does not then we have a problem.
Usually it happens because the nets are very small, maybe sitting next to each other, so the parasitics is so less that it gives min_cap.
Now, your tool computes delay according to i/p slew and o/p cap. So, when the tool has to compute delay for capacitance well below the 1st value in the cap table in library it will have to interpolate. This interpolation or extrapolation for extremely huge or low cap/slew values leads to extreme estimation by tool which is very prone to mistakes in computing the delay. The tools are pessimistic by nature and by default will give delay values far beyond what in real life that path would experience. Hence, you should have uncertainty enough to accomodate that mistake. It is commonly referred to as - extrapolation inaccuracy.
Like say the worst min_cap is 0.002 for which if the delay comes to be say 400ps.. which has 50% inaccuracy -> 400*50/100 = 200ps. So, if you have 200ps uncertainty then you can ignore these violations.
Thanks,
ro9ty