Path and resourceType both are used for registering the servlet.
When we register a servlet using path, we must be specific what all paths are allowed as If we define something randomly, our servlet might not be function properly. Only a limited set of paths are allowed and the rest are blocked. We can add more path using Apache Sling Servlet / Script Resolver and Error Handler. Allowing more paths to execute servlet to make your application vulnerable. like below image
That’s why you should not open more doors for servlets to run until and unless it is required. You might also need to tell specific paths to your consumers, who are consuming servlet response using ajax and any change in that path could have a serious affect.
This might not be the case when you use resourceType. Sling Engine will take care of permissions if you register servlet using Resource Type. Users who cannot access a particular resource will not be able to invoke the servlet.
There is a good article by Ankur. please check this and let us know if you have any question in this.
Binding servlets by paths has several disadvantages when compared to binding by resource types, namely:
path-bound servlets cannot be access controlled using the default JCR repository ACLs
path-bound servlets can only be registered to a path and not a resource type (i.e. no suffix handling)
if a path-bound servlet is not active, e.g. if the bundle is missing or not started, a POST might result in unexpected results. usually creating a node at /bin/xyz which subsequently overlays the servlets path binding
the mapping is not transparent to a developer looking just at the repository
Given these drawbacks it is strongly recommended to bind servlets to resource types rather than paths.
Path based servlets are deprecated as they are dependent on maven-scr-plugin (DS1.2/R4). If you plan to use R6 or R7 in latest version of AEM, then maven-scr-plugin is not recommended.