how is it secure when the miner is still using insecure http to send the user and password?
You can only change any settings with the account password, which really should be different from your worker password (which is only used for accessing the API, getting work and submitting shares, so nothing bad can come of others knowing it).
I think it could be used to connect and flood in random hash values at a high rate as a denial of service attempt [...]
Yes, and with any luck those values will be shares and up your share counter...

Seriously, though, this is not a security problem, which is what I was pointing out.
Also, why sniff worker passwords when you can just write a quick script that creates a couple of accounts with a couple of workers and use those for your flooding attack? It just doesn't change anything, and the extra overhead created by the SSL connection will put as much load on the server as a mid-size DOS attack (and cause more stales and idle miners).
There is such a thing as sub-optimisation...
