Quiese does prevent writes to the database.
I have a slight advantage in that I have seen some of the further details you included with the support instance you opened fo rthis issue. You might post the details of your command and script here.
You are quiescing the master database. The subsequent messages about being unable to modify syslogins comes from a succession of different spids - so I think this is from other clients trying to login while master is quiesced, which causes an update to a field in syslogins that tracks the last logged in datetime.
[ In the errorlog, the 4th field in on each line, 999 in this case, is the spid that generated the error
00:0022:00000:00999:2014/02/13 13:10:10.10 server Update of syslogins failed
]
I don't have any direct experience with sybctrl, I'm not sure why it seems to be blocking.
From the little reading I did, I had the impression you had to pass the isql binary you wanted to use as a parameter which you don't seem to be doing - however, you do seem to be getting masterdb to quiesce, so that may be a red herring.
Does sybctrl not block if you only quiesce non-master databases?
Do you have a carriage return after the final "go" in the script?
Perhaps try "select syb_quit()" + "go" + "" as the final three lines in the script?
-bret