Now I have tried the same client but choosing to use the hosted lock instead (which has the undesired effect of login redirecting to to show lock) and that works fine.
So is it the case that if you are using the Implicit flow (which I should for SPA app) then I am stuck and can only use the hosted lock?
The implicit flows implies a redirect to the identity provider/authorization server and in general it’s at that location that the end-user provides their credentials. This maps to the hosted login page scenario you mentioned.
In addition to that, there’s ongoing work to allow a redirect-based flow that would allow for the end-user to provide the credentials at the client application itself, but at this time this is not yet formally available/documented.
In relation to the error you got it’s because by default new client application do not have the resource owner password credentials grants enabled and the Lock configuration you’re using (the one from the sample) is trying to make use of that grant. In practice you could enable that grant for the client application, but have in mind that the resource owner password credentials grant is very different from the implicit grant and has some constraints, for example, there will be no session established at the identity provider so if you add another client application into the mix, the second one could not leverage SSO due to the lack of a previous session which would mean the end-user would have to provide credentials again.
In conclusion, the recommendation is indeed to use the implicit flow and the hosted login page as that would provide the best security characteristics with the less amount of custom work.