Pros and cons of rooting using apps ("Soft Root") compared to other methods ("Hard Root") There are quite a few app based rooting methods. A recent review 9 free software apps to root Android devices, points to some of them and there may be more apps, paid or otherwise.

From what I understand, 

Plus Points


Ease of rooting
Don't need a laptop or computer


Minuses


Based on exploits, so may not work if exploits are denied by OS updates
Difficulty in unrooting (as I see on some forums for my device Huawei Honor 6)


Questions: 


What are the pros and cons apart from above? 
If a device has both options - app based rooting and rooting by methods by developers, which one should I opt for?


Note: I am not seeking app suggestion or recommendation.
Thanks to AndrewT who posted a link on chat, having this research paper  as a refernce in one of the answers. This answer is entirely based on the this paper (May 2015) and highlights common user understandable aspects ( it has a lot of security related material for those interested)




  
  What are the pros and cons apart from above?
  If a device has both options - app based rooting and rooting by methods by developers, which one should I opt for?
  


Answer:  It's all about malware vulnerability. Using Root exploits is a HUGE security risk and that over-weighs any other advantages 

What is Soft Root and Hard Root?


Soft Root :  Root is obtained directly by
running a piece of software (i.e., root exploits)- either by directly installing on the device or  requiring adb shell through a PC connection
Hard Root :  Root is obtained by flashing su binary externally via an update package or ROM


Malware Threat - in general


Even though legitimate, many convenient one-click root methods operate by exploiting vulnerabilities in the Android system. If not carefully controlled, such exploits can be abused by malware author to gain unauthorized root privilege.
As described in the Android Malware Genome Project  ,  36.7% ( of 1260 ) malware samples had embedded at least one root exploit.
These well-engineered exploits are not well protected, it is extremely dangerous if they fall in the wrong hands.


Who are major root providers  and broadly, how does it work?



What are the types of root expolits ?

The paper covers 78 exploits studied. In general , the order of impact ( from the highest to lowest) : 


Kernel Exploits: Due to its privileged position, targeting Linux Kernel is natural to achieve full control over an Android device- example ,TowelRoot
Library Exploits: the exploits targeting libraries that are used by Android system processes, or external libraries used for supporting different applications, example ZergRush exploit , libsysutils used by Volume Manager daemon
Application and Application Framework Application layer root exploits : exploits targeting system applications or services, mostly include vulnerable logics introduced by setuid utilities, system applications, or services. example is a vulnerable setuid utility that is only present on XoomFE devices
that has a command injection vulnerability
Vendor-Specific Kernel or Drivers: Vendors either customize the kernel (e.g., Qualcomm’s custom Linux kernel branch) or provide vendor-specific device drivers for various peripherals (e.g., camera, sound). Such code runs inside the kernel space and the compromise of which can also lead to full control over the device. 


Number wise , exploits are as in figure below



How difficult is it to lay your hands on Exploit (Source or Binary) ?

Very easy. Easily available from Google search, making it a cake walk  for malware authors to leverage such exploits. Googling for 73 exploits lead to 68 of them being available - 46 with source code and 22 with binaries

How do these exploits work?

Major requirements for exploits to work (ordered from most difficult  to least) ( malware tag has a lot of these instances)


Requiring user interactions: (6 out of 78 studied)


Asking the user to download an app and manually interrupt the installation
Asking the user to boot into recovery at least once .
Asking the user to manually put the device into “battery
saving” mode . 
Asking  the user to open a vendor specific app and hit a button 

Requiring adb shell through a PC connection: (17 out of 78 studied). For some exploits, adb shell connection is required because of the following most common reasons:


The exploit can successfully modify a setting in local.prop which enables root for adb shell only.
The exploit needs to write to a file owned by group shell and group-writable (not world-writable) 
The exploit targets the adb daemon process that requires the attack process to run with shell user. For instance, the Rage Against the Cage exploit targets the vulnerability of adb daemon’s missing check on return value of setuid()

Reboot: (6 out of 78 studied)  Generally, many root exploits require at least one reboot. For instance, a symbolic link attack would allow an attacker to delete a file owned by system with weak permission, to setup a link at the same location to a protected file. After a reboot, the corresponding init scripts would attempt to change the permission of the original file  to world-writable, which in reality changes the permission of the linked file 
None or permission:  (44 out of 78 studied) The exploits in this category have no hard requirements, however, some of them may require certain Android permissions like READ LOGS in order for the process owner to be placed in certain user group.


Can these exploits be detected by Anti-Virus ?

Since the root exploits are highly sensitive and may be leveraged by various Android malware, it is expected that anti-virus software on Android platform can identify most of them, including the ones implemented by root providers. Overall, the result shows that the state-of-the-art security products on Android platform still cannot address root exploits effectively

4 representative Android anti-virus products  were used to test the largest provider (name not revealed) having 167 exploits. Because originally downloaded exploits from the providers  database have packed the actual exploit code and employed a tamper-detection mechanism, study crafted 3 different versions for every exploit:


Original exploit fetched directly from providers servers, with
packing and tamper-detection on. 
Unpacked exploit, which will expose all actual exploit logic to
    anti-virus products.
Re-packed exploit with tamper-detection disabled.


Exploit binaries engineered by large root providers are surprisingly “clean” as all major anti-virus software have difficulty detecting them as table below shows



Conclusion

Simple. Stay away from Soft Root methods unless you are capable of dealing with the consequences