I suggest reading through the FAQ and the Web Fonts and Reserved Font Names paper to make your own decision with all the facts and rationale about RFNs: http://scripts.sil.org/OFL-FAQ_web

RFNs are optional but they actually serve a purpose in various cases. (Document reflow issues, changes in coverage and features, unexpected bugs and support burdens coming from derivative versions are then clearly distinct from the canonical version because they have different unique names.)

Some people argue that uncontrolled forking, redistribution and publication of end-user facing fonts under the exact same name as the original is less than ideal. IOW breaking the namespace for end-users and other designers (or the Knuthian adage: you can modify it but please don't create chaos).

Having webfont services publish truncated subsets of a font (or with broken smarts) under the exact same name as the original for "optimization" purposes is also less than ideal.

When developing an open font collaboratively in a public repository, you can also use a development name that is different from the release name which users expect to be stable.

(Documenting changes in a FONTLOG.txt file is recommended but not required).

When developing an open font collaboratively in a public repository, you can also use a development name that is different from the release name which users expect to be stable.

For people keen on RFNs, I think this is essential :)

The web fonts / RFN paper says that I can give any webfont service a written agreement to use the RFN in subsets (should I ever get to that stage). But I would rather forks not have the same name. That suggests to me that an RFN is what I want.

I don't understand the benefits of a different development/release name - could you explain?