What is the importance of using asynchronous reset instead of synchronous reset?
This answer is valid for ASICs.

After reading few references on the net I discovered that the question "sync or async" is a kind of "iOS or Android" question. All the below is my opinion on the subject which is biased.

Async resets are pain in the neck because:


They are glitch sensitive
They must be deasserted synchronously
They must be deasserted synchronously, to all flops, at the same clock cycle
They can cause metastability problems if there are flops which are not reset


While section 1 and 2 are easy to handle, the rest are major issues which require thorough understanding and a whole lot of tools for validation.

And now the painful truth: async resets are still preferable for large systems. The advantages of async resets are:


Async resets have priority over any other signal
Async resets do not share combinational paths with other signals
Async resets do not require clocks


The fact that all the flops are reset, and that all the flops are out of reset at the same clock cycle is a major advantage (and if it does not happen on the same cycle, then this is indicated by tools and awaits for designer's decision). In complex designs (containing many clock domains where each clock is gated tens or hundred of times) it is very difficult to ensure that there are no corner cases when sync resets are used. Async resets are agnostic to these issues (there is still one place where async resets meet clocks - in the deassertion logic, which must be distinct for each clock domain).

The warning you see suggests that all your flops should be reset asynchronously. However, it is a matter of micro-architectural decision which kind of reset to use, and this should be consistent across some defined boundary. Still, if you're sure that non-standard reset is more appropriate in some place - use it and waive the warning. 

EDIT:

During scan insertion all the flops in a scan chain are required to function properly. If you're using an externally fed async reset then the above condition is very simple to satisfy - just tie the external net to a non-reset value. 

In a sync reset designs the above condition must also be satisfied. This is achieved in the same manner, but since sync resets may share combinational paths with other logic, the tools may erroneously detect flops which can get reset during scan (or not erroneously).

In light of the additional information provided in comments (no async resets at all and this warning is reported for all flops), I believe that you can disable this rule completely. On the other hand, you might want to ensure that your Lint DFT supports sync resets (i.e. it has parallel rules for sync resets, and these rules are enabled)

EDIT2:

I found this great article on the Web. I've never been to SNUG myself, but it seems like there are many designers who favor sync reset schemes. You can find pretty deep analysis of sync and async schemes in the above article, along with many practical advices.