Q:

Systemd units: [Install] vs. command: start (cloud-config)

I'm configuring systemd in a cloud-config file for CoreOS. If I understand this correctly, I have two ways of starting a unit at boot:
Alternative 1, use the [Install]-section (as described in digital oceans guides):
- name: initialize_data
  content: |
    [Unit]
    Description=Run a command

    [Service]
    Type=oneshot
    ExecStart=/usr/bin/mkdir /foo

    [Install]
    WantedBy=multi-user.target

Alternative 2, drop the [Install]-section and use command: start:
- name: initialize_data
  command: start
  content: |
    [Unit]
    Description=Run a command

    [Service]
    Type=oneshot
    ExecStart=/usr/bin/mkdir /foo

Is there any drawbacks of starting the unit using command: start? I get that I can't control which unit it will start after, but anything else? Will it honour [Unit]-directives such as Requires= and After=?

A:

It appears on CoreOS there's little difference. When systemd is used on other Linux distributions, the distinction is that start only starts up a service, it doesn't cause it to start on boot. That's what enable does, by processing the [Install] section of a systemd file. 
However, the CoreOS docs say that the cloud-config commands are processed on every boot. So by specifying a service to start  through cloud-config, the service is essentially enabled as well. 
CoreOS likely includes both options to give you the full flexibility of accessing both systemd features. 

