Most likely whoever wrote it cut their teeth on MySQL 4.0 or earlier which didn't have subselects.
They don't do this so much now, but back in the day (mid-late 90s) MySQL documentation was notorious for glossing over why they didn't have features. Foreign keys were "too slow". Transactions were "too slow", etc. If you need to rollback, store the previous values in memory in your own code, they told everyone (then quietly added the feature and changed the docs).
Why roundtrip to the db for the same user info again? I have seen this type of behavior in data access "frameworks"... the optimization would be to reduce the roundtrip to the db...
It's really amazing what poorly-written frameworks have done to the minds of people. When I teach classes on DBIx::Class (the Perl ORM), my students are shocked that $foo->bar->baz actually generates the SQL to follow the two relations as opposed to the "easy" "get list of results, then run query on each result, then return an array...". Actually, $foo->bar->baz, by itself, doesn't touch the database. The database is only contacted when you actually try to get information out of the result object. (And of course, the database is only queried once.)
Grabbing the users
SELECT * FROM `users` WHERE (users.id in (<list of user ids>))
followed by queries for each user id in that list
SELECT * FROM `users` WHERE (`users`.`id` = <user id>)
Maybe there's a reason for doing that, but if there is, I can't think of it