Oh dear, it's doing a separate BedellPenDragon::renderGetBpdProp() for every item, plus it's doing a separate getDisplayTitle() for every item. Not only that, BedellPenDragon::renderRandomPageInCat() does the same thing. Not a big deal, except on templates like ChildWiki:More new articles or ChildWiki:More featured articles. I believe this would be called an O(n) situation. It could get pretty ugly, if the number of articles were to get pretty high.
Probably the most potential for savings is when it's a query that can be done as a LIMIT x (e.g. a new pages feed) or selecting everything in a category, rather than having a WHERE with a bunch of individual pages to select from all over the table (as in the case of random pages). But I'm not sure. I'm no expert on database optimization. Maybe JOINs would make it more efficient; maybe not. Too bad I also know nothing about profiling.
Ugh, I just realized this could get ugly either way, because if I do a join on page_props for the displaytitle and the bpdprop, then I'll end up with multiple rows. So, the WHERE or the JOIN will have to filter for that, I guess (if we're going to reduce the number of rows to a max of three for each title), and then it'll be necessary to make sure each row is only going into the $retArray once. I wonder what the most efficient way will be? Probably to pull all the page_props for a page and just only use the displaytitle and the bpdprop.