Just to follow up on this: I looked into it more and it looks like alias is functioning as designed, and I was just wrong to suggest it as a solution here 
The technical explanation (if you're interested) is that alias is not truly a "wrapping" backend like combine, crypt, hasher, etc. -- you can think of it more as a "redirect" or shortcut to another remote. As a result, the Fs that bisync receives is the real dropbox remote, not an alias remote wrapping a dropbox remote. In contrast, if combine is used, bisync receives a combine remote wrapping a dropbox remote, which is why combine is really the better bet for this particular use case.
All of that said, I definitely agree that this kind of hacky workaround shouldn't be necessary to use bisync with long paths, and I will plan to address this as part of the "sessions" project, most likely by adding an option to specify a custom --session some_custom_name (for example.)
It's possible that --session hash could additionally be added as a shortcut to automatically hash the default name into a shorter md5. I would be interested in your feedback (same for any other bisync users who might be reading this!) about whether you would prefer this option to --session some_short_name, and if so why. (For the purposes of the question, assume that there is already some persistent config to store the long->short name mapping and other session settings, so doing it statelessly is not a requirement.)