We discussed this issue once, at:
The conclusion of the call was that adding exp was sufficient, and this was added for the second implementers draft. (I can't recall what the argument against requiring iat or nbf was.)
I'm not convinced the current situation is sufficient.
If we consider a mobile device that is a private client (via dynamic registration) then the end-user is in control of the current time on the device. If an attacker was to set the time forward and trigger an authorisation, they could obtain a request object that had a long validity (eg. years).
My understanding of the call was there was wide consensus that request objects should have a limited time period where they are valid.
In theory an AS could reject a token that expires a long time in the future, but I'm not convinced that would be considered compliant with the specifications.
I think requiring nbf is the only real way to mitigate the generation of request objects with long validity.