Use of API Sids has never been allowed in managed packages. These are allowed only in unpackaged code. The only issue is that there weren't automated tools in place to consistently enforce this. As these automated tools are rolled out, a lot of apps will start failing the review because of session Id theft and existing apps will start getting flagged.
To understand why grabbing a user's sid and then logging into another API as them is something we don't want managed packages to do, consider the following:
Impersonation: The logs will then record those calls as being done by the user when they were done by your app. If you use OAuth, you are logging in with credentials associated to the app and the logs will correctly track what is going on.
Lack of Authorization: If you are going to log in on behalf of a user to another service, then you should be authorized to do this rather than doing it without the user's consent. In Salesforce the admin can pre-authorize you and so grant consent on behalf of another user, but an app can't authorize itself. With OAuth, there is an authorization step so that you are not silently stealing credentials and taking actions without the user's approval.
Lack of Scoping: We want to follow the principle of least privilege and scope down the allowed operations to be as close to what you need as possible. OAuth allows you to choose and even define scopes, whereas API Sids have no ability to do this.
Namespace Escape: All code running in a managed package should be scoped to a namespace. Any attempts to break out of that namespace and run in a different scope are considered vulnerabilities in the security review. This includes attempts to grab the session id of the salesforce origin via a weblink as well as attempts to grab the API sid, which is not namespaced. If an admin uses your app, you could grab that admin's sid and then uninstall a package in a different namespace, or install an apex class in the unpackaged namespace. That is a clear escape from your own namespace.
Because of the above risks, API Enabled Sids are considered unsafe and there are both on going efforts to remove them from the product as well as automated and manual efforts to flag their usage in managed packages. Over time, these efforts will get more and more strict, so please avoid them now, and if your app is using them, please start refactoring your app to use OAuth instead.
This is basically a continuation of the home page component issue, which is another ongoing locking down of the platform to prevent use of credentials that don't belong to the managed package.