In a formal review of an application's security, all libraries should be vetted for security defects. However, this is not the point of OWASP-2013 A9. The core of OWASP-2013 A9 is about having a policies in place to ensure that an application isn't compromised due to negligence. OWASP states the following:

1. Identify all components and the versions you are using, including all dependencies. (e.g., the versions plugin).
2. Monitor the security of these components in public databases, project mailing lists, and security mailing lists, and keep them up to date.
3. Establish security policies governing component use, such as requiring certain software development practices, passing security tests, and acceptable licenses.
4. Where appropriate, consider adding security wrappers around components to disable unused functionality and/ or secure weak or vulnerable aspects of the component.

Number 2 is the most important. If you are dependent on a library or platform, these components need to be updated regularly. Internally there should be a cycle to review all components and versions, and ensure that these are fully updated. A monthly cycle to review these components would be ideal.

In short number 4 is requiring strong validation of input to untrusted libraries. If a library hasn't been fully tested for security defects then data passed to this library must be validated. It is a very good security practice to do this for all input. An example of this is using an OWASP ESAPI validation routine for all input. So if it is an email address, it should match a regex for email addresses.

The reason for the delay is that there has been little change in the Web T10. As stated by Dave Wichers, the Web T10 project lead, on 30 June 2015:

Historically, we've produced a new OWASP Top 10 every 3 years because this seems to balance the tempo of change in the AppSec market, all the work everyone does to map their tool/process/other thing to each version of the OWASP Top 10, and the effort required to produce it. We've been producing a new one every three years since 2004 (i.e., 2007/2010/2013), and so a new version for 2016 is due. (Definitely not happening in 2015).

However, we've been thinking about what might change in a 2016 release of the Top 10 and we don't actually think it would change much, if at all, which is kind of sad actually. I suspect some Top 10 items might move up or down based on the vulnerability prevalence statistics that we would need to gather and process, but I have my doubts that any new vulnerability types would break into the Top 10.

As such, given that we don't expect the list to actually change in any substantial way, the project has decided to defer the next update to a 2017 release.

This table from the 2013 T10 Release Notes demonstrates the small change: The changes were largely due to rethinking how to categorize the raw data, not due to significant changes in the data.

Some have postulated that the level of effort for creating the T10 was a factor for delaying it. While it is a lot of work, I do not think that was a major factor. The Web T10 is OWASP's most recognized project and always has lots of volunteers (I contributed to the 2007, 2010, and 2013 ones).

Speculating as to whether the same thing will happen for mobile applications, I do not think that is likely in the near future. Mobile technology is still in its infancy and subject to rapid change.