Currently syslog is started in the S10boot script.

This does no good if the -R option is set. 

Perhaps it should be moved until after networking is started?  Or at least have a "restart with user options" if it must be running before networking.

This again would be bad if you are using syslog -C and want to see syslog entries from startup scripts before networking.

Just as this. Restarting syslog in circular mode would delete the log stored previously.

Why not just move the startup script down manually in "special cases" as you need to do with lots of other scripts?

Two reasons.  One is purely selfish

1) Because i every little bit of space counts.  If it can be done a certain way in /rom, then i would love to see it rather than use precious jffs space.

2) If the unit doesn't boot, you're not going to be able to get onto it to check its syslog anyway.  by starting syslog when i do (and with the remote options) i acutally get a log of whats going on during boot before i can even log on (the only thing that starts before it is networking, and if that doesn't come up you're hosed anyway).

If the boot fails before dropbear starts, or have problems logging onto the box, at least i have a chance to know what went wrong.

I can't follow your agrumentation.
# rm /etc/init.d/S10syslog
# ln -s /rom/etc/init.d/S10syslog /etc/init.d/S50syslog

But people (take me as an unrepresentative example) might want to see what went wrong (or right) before networking loads, even when everything else did load correctly.

It might be a trade-off to start circular syslog in S10, and do a "logread > /tmp/boot.log; killall syslog; syslog -R ..." in S50, but I am not sure if this really needs to be done in the core build, since the only purpose will be to cover a pretty special case.