I've run a testing session, as this temperamental behavior was bugging me. I was able to establish a 100% reproducible pattern (nothing really new&exciting here, just confirming older reports and summing different things up):

1. When hostmode goes haywire (doesn't want to enumerate device properly, give absurd errors about different speed-type device connected, or device "not accepting addres <>blabla>"), switching to USB peripheral with charging (aka disabling hostmode) *and* connecting briefly to charger fixes it. After disconnecting from charger and re-attempting, device enumerates like charm 100% times.

2. What is even more interesting, is that hostmode with charging *also* counts - i.e, if I enumerate device successfully, then switch to Peripheral (disable hostmode), and try to enter hostmode again shortly after (tested in less than minute), device fails to enumerate 100% of times. Hoever, if - after enumerating device successfully - I connect to charger (y_cable), enable hostmode with charging, then, disable hostmode and enter peripheral, I can re-enable hostmode and enumerate device without any problems, immediately.
---
Summing it up - just like known thing about possible "standby current" after using hostmode ("reset" by connecting to charger), there is something else, that interferes with hostmode, and get "fixed" by device entering into charging state. I suspect, that even "cheating" it that it entered charging - without any physical charger - would do the job, to, just like with fixing "standby current" bug.
---

It's a pity that we don't have competent kernel coder - knowledgeable about USB - handy - definitely something is "fishy" about chip's states after enumerating (successful or attempt). Maybe it is limitation of our hardware and patchwork hostmode, but, even then, hardcoding a forced "fake charging state" after every hostmode disabling (entering peripheral-ready mode), would - probably - serve as extremely dirty, but working, workaround.

/Estel