There is a way to do it with SimpleDB but it isn't elegant, it's more of a hack since it requires you to artificially duplicate the userid attribute in your submission items.
It's based on the fact that although you can only have 20 comparisons per IN predicate, you can have 20 IN predicates if they each name different attributes. So add additional synthetic attributes to your submission items of the form:
userID='00123' userID_2='00123' userID_3='00123' userID_4='00123' ... userID_20='00123'
They all have the identical value for a given submission. Then you can fetch the submission of up to 400 friends with a single query:
SELECT * FROM submissions
WHERE userID IN('00120','00121',...,'00139') OR
`userID_2` IN('00140','00141',...,'00159') OR
`userID_3` IN('00160','00161',...,'00179') OR
`userID_4` IN('00180','00181',...,'00199') OR
...
`userID_20` IN('00300','00301',...,'00319')
You can populate the 19 extra attributes at the time the submission is created (if you have the attributes to spare) and it doesn't sound like a submission's user would ever change. Also you may want to explicitly name the attributes to be returned (instead of using * ) since you would now have 19 of them that you don't care about in the return data set.
From the data model point of view, this is clearly a hack. But having said that, it gives you exactly what you would want, for users with 400 friends or less: a single query so you can restrict by date or other criteria, sort by most recent, page through results, etc. Unfortunately, a capacity of 400 won't accommodate the friend lists of all facebook users. So you may still need to implement a multi-query solution for large friend lists just the same.
My suggestion is that if SimpleDB suits the needs of your app with the exception of this issue, then consider using the hack. But if you need to do things like this repeatedly then SimpleDB is probably not the best choice.