1. because in general parameters do mean queries, they are not static resources, they are dynamic API results.
   Some do work as plain URIs, like https://anyx.io/v1/database_api/get_dynamic_global_properties, as this has no parameters.
2. the /v1/ variant is backwards compatible and easily translatable from the original POST variant to the RESTful one. Better URIs (but breaking compatibility) can come in a v2.
   consider something like https://developers.steem.io/apidefinitions/#database_api.list_accounts
   The mapping is intuitive, instead of POSTing
   '{"jsonrpc":"2.0", "method":"database_api.list_accounts", "params": {"start":"steemit", "limit":10, "order":"by_name"}, "id":1}'
   you can instead do
   http://anyx.io/v1/database_api/list_accounts?start=steemit&limit=10&order=by_name
3. the current steem appbase apis require the object name (e.g., as above, they require knowing "start" as well as the value associated). Including it in the request clarifies the mapping.

This is how restful implementations work typically. You have parameters to format the specific data you are interested in.