I agree to the article beside the part about the clustering key and Fillfactor. The author argues, that he sets the fillfactor to 90 to prevent page splits. This would make only sense, if he uses GUIDs, which are used in the merge replication, but not in peer-to-peer.
Lets assume, we have server1 which uses the IDs 1 to 1 Mio and server2 which uses 1,000,001 to 2 mio. Both servers have used the half of their range and you rebuild the index. Now you have a single page with ID 500,000 (from server 1) followed by ID 1,000,001 from server 2.
When server 1 now inserts a new record, it needs a pagesplit, which would (ideally) place the 1,000,001 on a new page, so that 500,001 could be inserted on the now free space in the half-empty page. When you insert more records on the server 1, they would all land on this page too and when it is full, it would create a new page. Inserts on Server 2 would never result in a page split, since it occurs always on the latest record.
And when you would use partitioning (on the ID column with using the id 1 mio as split value), you could prevent the whole pagesplitt stuff per design.
Another point: how often do you insert records compared to reads? In the most tables the inserts are single row inserts at the end of a page and mostly "user driven" where a single minor page split does not make any noticable differe to the response time.
On the other hand a fill factor of 90 % means, that 10 % of your table / database are empty - on pages, where you NEVER insert any record (when you are using an sequential integer as clustering key). So you have to read / buffer 10 % more pages, when you do a select / update / delete (and even some inserts because of FKs), 10 % more backup time / restore time / space on the disk etc.
If the table is read only (as logs) or the columns are all fixed size (not nullable int / datetime etc.), you can use 100 %, when the size of a record can grow because of user changes (e.g. changing the name to a longer one, adding a comment, or setting a NULL column to a value), I tend to use 98 or 99 as fillfactor (since the most data are static particularly when they are no longer "hot")