There are several disadvantages to using regex analysis rules:
The regular expression that is generated is based on the response variant seen during the test execution at the time you added the analysis. This means any response variants seen on different product types, versions, etc. might cause the analysis rule to “fail” due to an inability to match the regular expression. Response maps are flexible and can be created to account for common variation in command responses. Also, if you are using testbeds to quickly change between devices for execution (for portability) then you may hit failures due to command variation between the devices. A new version of software may also invalidate your regular expression which means you will have to update all your test cases instead of making the change just once in the response map.
If you have several occurrences of the response throughout your test case (or even through multiple test cases) and if you need to change the regular expression used in the analysis rule, you will have to make this change in several locations. Using a response map means you can make one change that will propagate throughout all your test cases that are using the response map.
Using a Regex analysis rule means that others (who may not understand regex) may find it more difficult to understand what data you are attempting to extract from the response. Using a response map means that data is identified by queries which have easy to understand names. For example, a query named “Version()” is much easier to understand than a longer regular expression that is trying to match the specific version string in a command response.
The [Response Mapping] tag is dedicated to response mapping questions: : /questions/topics/Response+Mapping.html