There is no ambiguity in the USB spec, and Sarah has an incorrect interpretation. The spec requires that the host provide at least 10 ms of recovery time coming out of suspend; a device is required to be able to communicate after this minimum time. Any device which isn't ready for communications after 10 ms of resume recovery time is broken. A host is permitted to provide more than this, but isn't required to.
So, yes, it's perfectly valid for the host to blindly attempt to communicate with the device after 10 ms - presuming that the host KNOWS precisely when the recovery period began. If the host requested that the bus resume, set a timer for 10 ms, and then tried talking, the HOST is at fault because it didn't check with the hardware as to when the resume period began. I think the 17 ms that they reference in the article is related to this - there is a delay between the request to resume the bus and the actual time that the hardware does resume the bus, so they were trying to talk with devices before the 10 ms period was up.
The device is perfectly within the spec if it ignores communications prior to 10 ms, or if it responds to them - it has complete flexibility. After 10 ms, however, it MUST be ready to communicate.