The issue (if it isn't obvious) is that the user you are running the command as does not have the permissions to execute it. As @CharlesDuffy noted in the comment's:

If it's just direct output from curl -o, there won't be any x bits at all, so I'd expect rw-r--r-- or rw-rw-r--, depending on the active umask

What do the permissions look like for the executable? You can find that by running:

ls -l /usr/local/bin/calicoctl

The results of the above command will output something similar to:

-rw-r--r-- 1 root root 1680446 Jul 16 11:56 /usr/local/bin/calicoctl

Where the rw-r--r-- portion refers to the allowed permissions of the Owner, Group, and World/Global respectively in three letter chunks. You can read more about how permissions work here.

I have a feeling you're results look similar to rw-r--r-- which would mean no one has the ability to execute. It's common that all binary located in /usr/local/bin are owned by root, are in the root group, and have permissions set to either rwxrwxrwx (where everyone can Read/Write/Execute) or rwxr-xr-x (where the Owner can Read/Write/Execute but Group members and Global can only Read/Execute.)

To can try to adjust you're permissions to rwxrwxr-x with

sudo chmod 775 /usr/local/bin/calicoctl

and see if that works. chmod is the tool used to change permissions. Again, see this link for more info on permissions in Ubuntu/GNU+Linux.

For reference, here is a numeric breakdown of user permissions:

7 - full (rwx)
6 - read and write (rw-)
5 - read and execute (r-x)
4 - read only (r--)
3 - write and execute (-wx)
2 - write only (-w-)
1 - execute only (--x)
0 - none (---) 

You can also probably just run your initial command with sudo but that's not a solution, just a workaround