1. What was the reasoning as to why <img>, <object>, etc. tags were left out (well, any element with an 'src' attribute)?  It seems unreasonable to think such a point was not considered (indeed, there is even the following in the SRI spec: ..."A future revision of this specification is likely to include integrity support for all possible subresources, i.e., a, audio, embed, iframe, img, link, object,"...  so I'm interested to find out why only <link> and <script> tags were included initially.
    
2. Has any work been done to assess the impact of SRI with regard to mobile devices? If SRI attains wide-spread adoption, does the added load of calculating and comparing hashes have a noteworthy effect on battery life or responsiveness of popular devices such as smart-phones and tablets?
    
3. By my understanding, there is a one-to-one mapping between the integrity attribute and the sub-resource. This implies pages and sub-resources must always be updated in-sync. By allowing multiple integrity attributes (i.e. multiple cryptographically validated versions of a sub-resource), there is the (very low) risk that an attacker has more options for a collision, but it would permit developers and administrators a freedom which makes implementing SRI vastly more practical. Again, I presume this issue will have been thought about, and I'm interested in why such a capability is missing (see *1 below for an example use case).
    
4. Are there any 'practical' guidelines or recommendations for web developers implementing SRI in applications? E.g. should it only be used for non-origin hosted resources, should developers provide multiple (or only one) hash in each integrity attribute (they can use many, what should they do?), is it recommended to limit SRI use in pages expected to have a large mobile-device audience (e.g. always for JS, optional for css) etc. etc.