No, when utilizing a REST protocol it is not desirable to have long requests. The correct way to do something that could potentially take a long time would be to process it in the background queued and then have the client poll the server until complete or to push it to the client when complete.
Having an open connection for 30 seconds + is bad practice, and App Engine is a shared resource. Arbitrary limits are sometimes bad but in this case it will deter poorly designed APIs from starting in the first place.
But the developer is in the best position to decide whether he should fix the code. Perhaps he's just testing something, that will be rewritten later. 30+ seconds requests are not always bad.
It has a cost (it takes time to fix it) and value (users won't have to wait). The developer has more information than Google to decide whether cost or value is higher.
Out of curiosity, can you describe a situation where 30+ second requests on a large-scale, high-traffic system is acceptable (in the sense that it is better to hold the connection waiting rather than erroring out)?
EDIT: long-polling aside, and even then, 30 seconds is a perfectly acceptable limit.
Realtime updates (if you're not using Websockets) are usually done with long-polling, for which 30 seconds is perfectly acceptable. Socket.io, for example, uses a default of 20 seconds [1].
Streaming music and certainly video are generally delivered as chunks, with a few chunks per request that don't require long connections [2].
Having an open connection for 30 seconds + is bad practice, and App Engine is a shared resource. Arbitrary limits are sometimes bad but in this case it will deter poorly designed APIs from starting in the first place.