On the other end, pagination is rarely used on Android, and calculating the height of a single row can be more expensive since it has to layout the children hierarchy for a row according to the screen dimensions.
This type of layout is generally limited to social feeds, where pagination is pretty much mandatory (you have to request more results from an API). Anything entirely client-side typically uses fixed height rows.
I see your point, but this layout is used also for variable height images, variable lenght text, compound layouts, etc. The equivalent of pagination on Android is usually done using pull to refresh (horizontal swipe gestures are usually used to change topics more or less).
For something completely client side it is possible either to specify a fixed height or change the smoothScrollbar attribute of the listview (it is more expensive though and not used very much).
Nobody complains, I guess everyone is just used to the way it is. :D