I believe your method is better because it allows easy reporting and it's more flexible. It would also allow you to aggregate historic data into fewer records ie put all the member points for the year into one record rather than 12 after 5 years say. If at some point in the future you want to store member points by the week rather than by the month then your method will still work while the other method makes this impossible.
Their method is likely to be marginally quicker on the reporting side as it will pull back 1/12 the number of rows but this has to be offset against the more complex code that's required.
Normally you'd have a from_date and a to_date which would allow any type of period to be stored - this would allow you to group all the member points for a year into one record.
I concur - your method is a better design (first normal form justifies it alone). Apart from the flexibility issue - you can't just measure size on the basis of the # of rows since your design ensures much narrower rows. I would imagine you would not record zero points for a month in your design. If someone earns no points from feburary onwards then your design is actually more efficient with regards to table size. But this is secondary to the other points raised above.