Is the "Username-Password OAuth Authentication Flow" the least secure flow?
Yes. The documentation for this flow suggests that you should only ever use this for development in lieu of using an appropriate flow (Web-Server, User-Client, etc). You can use it to wire up an access token while you're working on the main app, before you've implemented the main login flow.
What possible security issues should be taken into account when using this flow?
You have to store the user's username and password on the device, or require the user to enter this information every couple of hours (session timeout value). You will not be issued a refresh token. This means that, unless you do the value store correctly, you're risking exposing authentication data unnecessarily.
At least with a refresh token, all you have to do is revoke the session to lock out a stolen session, while with the username-password flow, you'd have to require the user to reset their password and change it for all programs that use the password (e.g. Data Loader, other older systems that don't support OAuth, and other programs that use username-password flows).
Technically, your app won't even pass a security review if you use this flow, and salesforce will probably revoke your client_id to prevent compromises if you use this flow in an app.
Finally, the client_secret is a secret, a password that should considered secret. Client apps are inherently insecure and should not contain the client_secret. Exposing this value means if it's leaked, you'll have to change your client_secret in the master configuration, and update this value for all affected apps and servers.
In the event of a client_secret compromise, malicious programs can masquerade as your program, appearing legitimate while actually having nefarious purposes. This is why you don't want your client_secret floating about.
grant_type, client_id, client_secret, username, password will be sent as URL parameters. Is it possible to POST these parameters as JSON?
Yes, you can choose to use GET or POST. The documentation actually suggests using POST, as it uses the term "request body", which starts after a pair of newlines. It will be the same query string (name-value pairs with escaped URL characters for reserved/recommended escape characters) as you would produce in a GET request, except that it appears in the body instead of the header.