The original intent of plugins was to extend the functionality of MQ2. Whereas macros were designed for automation.
We overlap in that area, but the reason for that design is that MQ2 doesn't deal well with concurrency in automation. Concurrency just being "doing two things at the same time." Whenever there is overlap in concurrency, there is usually conflict because the system wasn't designed to handle it.
In that aspect, it's not really that different from the idea of "running a macro while actively playing your character." It's not that you can't do it, but if you're trying to cast your rotation and your macro is trying to cast a different rotation, you're going to run into issues. Once you know about those issues, it gets easier.
This is the same with automation in plugins.
MQ2Nav is a great example of a plugin that's "on the line" as far as automation goes. It's something that couldn't be done in a macro, but if you've ever used Nav on a fresh setup and tried to stop yourself in the middle of a route you'll see the conflict I'm talking about (your character fighting you to stay on route). Nav deals with this by adding TLOs to let you check what is going on.
Other plugins are just macro logic rolled up into different code. This is because the idea of "inc" files never really hit it's peak. It's not that you can't do something in a macro, it's more that you want to do one small thing and having to edit in an inc file to someone else's macro every time they update gets tedious. But for "shared logic" that was really meant to be what an inc file is for -- a file that contains just the logic itself and does one specific thing really well.
From a distribution standpoint, as a community we've tended toward the "one file" approach. Probably out of lack of organized distribution and tracking methods to start. You can see this in the way that most plugin cpp files are written, in the way that distributed macros are written, etc. That's likely another reason there is overlap in those areas.
But, getting back to the original question. Start with a macro. It's a good way to get your feet wet and decide how you want to do something. Macros are extremely forgiving and since they don't require compilation and most commands can be
/echo'd to see what's going on, they're mostly easy to work with. There are also a lot of great resources in that area to provide guidance and help.
When you hit a solid wall because you're missing something that you could really use in a macro, that's when to start looking at plugins.