Ultimately this looks like an opinion based question, I will give you my two cents:

Option 1:

The server application will have to create a framework to remember the values written for each "command" if that is necessary. "Command" implies that writing on a particular command will end up performing certain procedure, and nothing too complicated, in that case Option 1 is a good option. If however, you need to remember the values written for each command (which is implied since you want to support read), then you will have to write code that is already written by whichever BLE stack you are using.

Option 2:

This looks good if you already know the number of commands you will support, hence the number of characteristics you will have, there is an overhead of discovery involved. The client will have to discover all characteristics at the beginning and remember which handle belongs to which UUID and hence which command. This, while involving some extra complication, will provide more flexibility to specify permissions for each command. You could have a command require encryption/authentication/authorization to write to, while keeping other commands with different permissions. You could also have different write properties, commands that only accept read or write, notifications/indications independently for each characteristic, size control for commands that will always have a particular size, better error code responses, etc.

If the requirements are only and exactly as you specified, then both options are fine, you could probably toss a coin and let fate decide, note that my recommendation is the second option.

If there is a possibility to extend functionalities in the future, I will only recommend the second option.