Ok, so feel free to post links to these blog posts you're referring to. I guarantee you that they're just discussing general practice, and that's the problem with articles like that... sometimes they don't give good practical advice.
Here's a situation where this could come in very handy... and in fact, it's the very situation that the feature was designed for.
I have a client currently who has like 65 DBs on a server. They have all their data files on 1 drive, and all their logs on another drive.
A couple times a week a very large import comes through in the middle of the night and blows the log out to like 90GB. Then the log backup comes along and backs it up, and truncates the log, but the file is still 90+GB.
Sometimes, the other log files on that drive also need to expand but they can't because that file is too big. And it's mostly empty.
Now this file is tripping space alerts, other processes are failing, etc.
And the DBA has to get out of bed, diagnose the problem, and then shrink the log so that there's room for the other logs to expand.
Then other teams have to get involved because their processes got rolled back and they have to figure out what's there and what's not. This is a ridiculous situation.
He manually shrunk the log to fix this issue. But before that, several things had to fail, Then the NOC had to be called. Then the NT guys got woken up for the space issue, then he discovered it's a SQL issue and the DBA was finally gotten out of bed. And all that because the log got blown out much bigger than it should be.
Now, is the perfect fix for this to add more space? Yes and no. Some companies don't have that much space to give so they have to run things a lot tighter. But there's a larger aspect to this. Your recovery.
You may have an RTO of like 30mins. But the log has to be zeroed out every time so when you try to restore that DB somewhere, you'll have to zero out 90+GB of log file. It'll easily take your entire recovery time just building the log file. In fact, to write 90GB of log you'll very easily double that time just in log... and that's before you even get to the data part of the restore.
So keeping your log really huge because it gets blown out that big sometimes isn't always practical.
But if you see how I built the feature, I give you options. I don't just shrink the log every time. You can say that it only gets shrunk if it grows over a certain size. And then you can tell it how much to shrink it down. So we're not always just shrinking it. You can say, hey, I only want my log to be shrunk if it's over 25GB and then just shrink it down to 10GB. And you can configure those thresholds on a per database basis.
As a DBA, not using this feature in a case like this is doing yourself and your company a disservice. There's no reason to get teams of people out of bed for a temporary issue. There's no need to stop several other DBs for a temporary issue. And there's no reason to not fix a temporary issue with an automatic process when you apply the same fix every time.