Deprecated functions / features work fine in your current SQL Server Version. It is just a hint for you that in future versions of the SQL Server these functions will be dissmissed or replaced by others.
It doesn't mean that these functions are removed in the very next version, but it is planned in long term to remove them.
A list of deprecated features is available here: Microsoft SQL Server 2016 Deprecated features
SQL Server's transaction log files are made up of Virtual Log Files (VLFs). When you shrink a log file, it will only release unused VLFs at the end of the file. There is always going to be at least one VLF that is being used for current activity.
Consider this simplified example. You have a Log file that is made up of 6 equally sized VLFs. For simplicity, let's say 1 VLF = 1MB, so the total log file is 6MB. You want to shrink it to 3MB. You perform a transaction log backup, which makes some VLF (we'll pick 4 at random) active, and the rest available for reuse:
1____2____3____4_XX_5____6____
Now you perform a shrink with a target size of 3MB. Shrink can only lop off the unused VLFs at the end, but cannot go all the way down to the target size of 3MB:
1____2____3____4_XX_
You can't shrink any further, because VLF 4 is in use, and that's just how things work. You need VLF 4 to be available for reuse before it can be truncated. So you take a second transaction log backup--VLF 4 gets backed up, and VLF 1 becomes the active VLF:
1_XX_2____3____4____
Now, you can perform a second shrink, and get the transaction log down to the target size of 3MB:
1_XX_2____3____
Best Answer
As someone working for a large software vendor, I can say that undocumented and unsupported1 features typically fall into one of these three categories:
Tools for the exclusive use by the vendor support engineers. They are rarely needed, typically require intimate knowledge of internals, hard to set up and use, and often dangerous enough to be protected by one-time passwords or keys that should be explicitly provided by the vendor. They are never intended to become product features. They are there to aid support when troubleshooting hard to debug problems.
Fixes and workarounds for esoteric bugs. They are implemented as hot fixes for critical situations. Such bugs are rare, and their root causes are eventually resolved, so these "features" lose their usefulness at that point, and it's not in the vendor's interest to provide continuous support for them.
Beta and experimental features. They are typically first made available and sparsely documented for a small cohort of beta testers and major customers who requested them. Some of these will eventually become fully supported, some others will be left there to rot when stakeholders lose interest or when they conflict with other features that are deemed more important or useful.
As mentioned in the comments to your question, each fully supported and documented feature carries a cost to the vendor, and that cost must be justified by the expected benefit. If there is little benefit to the vendor from maintaining a certain feature, there's no reason to support it.
1 - They are not really totally unsupported; they are supported on a "best effort" basis, meaning "We might have a technote somewhere that briefly describes the feature, but we won't spend much time helping you make it work, and if it doesn't work or if it wipes out your data, well, tough".