I read through the slides and I still don't know why he wrote his own rsync.

It's a bit easier to follow in the video since he talks from the slides more than presents them but as built up earlier in the deck (11-15) the router7 system us is written in pure Go, i.e. there is no other userspace, which comes with several neat advantages over a traditional system but he wanted to merge his routing box and server box as part of the upgrade needed to support 25G. Later (20-21) he talks about how all of the other software already had popular Go alternatives that could be easily dropped in except rsync and how there was a kludge way to get rsync on the box but it broke the advantages of doing the router7 Go only approach to do so and as a result he set out to implement enough of rsync to meet his needs.

The journey and results are much more interesting than the why though. Router7 has some interesting diagnostic capabilities and workarounds specific to issues he's had from the ISP. Also the implementation of rsync itself is interesting in that it outperformed canonical rsync of the time doing the same task without "better performance" being a goal while writing it. There are limitations with this implementation though, it was only made to meet the particular use case not be a general rsync replacement and it doesn't have the latest protocol/hashing changes rsync has which allowed rsync to retake the performance lead since.

The short sum up would be "because he had an open router userspace written in pure Go and rsync didn't have a suitable pure Go implementation at the time". No taking over the world or anything like that just good ol' hacking for personal use.