I’m new to ST, and very impressed so far. My main use is to automate/control z-wave lights etc.
Having searched for this topic to no avail, I thought I’d ask if there is a guideline or list of pros/cons on using Automations vs SmartApps as it relates to controlling lights.
I see where things like presence is available in SmartApps but not Automation., but I’m sure there are many other differences.
Presence is available in automations. 
to an extent
There’s no particular guideline.
The SmartLighting rules you create through the smartlighting smartapp are the only parts of the system at present that can “run locally“, that is that will still operate even if the Internet is out or the smartthings cloud is unavailable. So a lot of people always start with those because they want to get the local operation.
The design intention pretty clearly is to have everyone use automations unless they are power users who will eventually be writing custom code through the “rules API.“ However, as of this writing, December 2020, there are still somethings you just can’t do with the built-in automation creator. So they go to Smartapps to fill in the gaps.
So as far as what most people do, I think most people who just buy the system and set it up without ever coming to this forum just use automations.
People who do more research and want local operations put as much as they can into the smartlighting smartapp.
People who do a lot of research and are comfortable with custom code use custom code when there are features that they want that are not supported by the built-in automation creator. Sometimes that’s because they bought a device/service which has advanced features that require a smartapp, sometimes it’s because they asked a question in the forum and the answer was custom code.
Other than smart lighting and the third party RBoy smartapps library, the most popular smartapp for Power users is unquestionably webcore, which is a very advanced rules engine that can do a lot more than the built-in rules engine can. But that’s a whole other conversation. 
See the community FAQ (the topic title is a clickable link)
And the following is a very good example of a feature that should be in the built-in automations but just isn’t, so people have turned to smartapps to fill the gap:
There is a bit more to handling typical lighting scenarios than can be written with very simple generic logic. Relatively simple things like turning lights off after a delay when motion sensors go inactive, but keeping them on if the motion sensors come on again, requires something a bit more capable, or something bespoke. The Smart Lighting app makes a pretty good fist of a range of lighting and switching scenarios on the whole.
Smart Lighting does have flaws: the ‘toggle’ function doesn’t toggle the current setting of a switch, it does the opposite of what the app did last time; and when multiple motion sensors are used to control a light they and handled separately instead of being 'or’ed together.
Automations, in the sense of Automations in the mobile app, arrived later at the party. They have a very simple logical structure. However they do have some of the bespoke logic needed for things like switching and lighting, but it is hidden as options to conditions and actions. I, personally, struggle with it, because not only is it not particularly clear when Automations are evaluated, it isn’t always clear what the options are meant to be doing. It is an interesting idea though.
For some reason that the community seems to be struggling to identify, the apps’ built in mobile presence devices are being filtered out from device lists in the app, and do not appear as devices in Automations. They are used as the source of a ‘Member location’ in Automations, though peculiarly the presence is not displayed anywhere.
If I got it all right, local control when the internet is out seems to be the main + of SmartApps over Automations.
After having internet problems on Christmas day, I may have to move everything over to SmartApps.
Only the smart lighting smart app and only if all your devices run local.
Can you please add some clarification on the part where you mentioned “only if all your devices run locally.”?
How would I know if this is true?
If you login to IDE and look at your devices, it will show if the devices are local or cloud.
Devices using custom device handlers will be cloud.
You can also check smart lights rules under location > smart apps to see if they are local or cloud.
Sorry. Still unclear on this…
I take it IDE is something beyond the smartphone app, for people wanting to do development type automation. If that’s incorrect, pls clarify.
Also I am not seeing Location as an option under SmartApps or Smart Lighting. Im thinking i am not in the right place. Any thoughts?
The IDE Is the web interface to your smartthings account. 
There is some information there which is not available through the app itself. (It is also used by developers who are adding custom code, but that’s not the only purpose.)
Also, as @Automated_House mentioned, it’s not that there’s one category of “smartapps“ that has different features than “automations.“ Technically smartapps are also automations. The terms have changed over time and it does get confusing.
The original terms were “smartapps,” which was any code that ran in the smartthings cloud.
SmartLighting was a smartapp written by SmartThings staff and was and remains unique in that it is distributed with the firmware for the hub and so is available to run locally in some regions, including the US and the UK.
“Automations“ was a new term introduced with the new V3 app in 2018, and at first was just a fancy name for “rules.“ You’ll see in the app that rules that you create through smartlighting, for example, as shown in the app as “smartLighting Automations.“
But overtime, the new rules engine introduced with the V3 app became more sophisticated, and The rules you create when you click on the + in the upper right corner of the app and select “automations“ still run in the smartthings cloud, but are now distinguished from “smartapps“ which you can add as custom code through the IDE.
It’s all pretty confusing, but the main thing is just to know that there isn’t some major official distinction between the two categories, if they even are two categories. They’re just different terms used at different times in the smartthings documentation, and not used very consistently at that.
But at present, the biggest distinction is that only rules created through the official smartlighting feature are eligible to run locally. And even then it depends on the exact details of that rule. For example, you cannot change the mode locally.
To be honest, if local operation is important to you, smartthings isn’t the right platform to begin with because it’s still mostly a cloud-based system. There are a number of competing home automation systems, including Hubitat and Homekit, which run primarily locally. So it’s certainly possible, but it’s just not how smartthings is designed.
Good info. Thank you! I’ll have to see if running locally is that important to me. The Internet here is fairly stable so maybe I’m getting concerned about something that will not happen often.
Given that things evolve SO fast, I figured I’d add my two cents to this topic:
Given that Automations are the future as far as I can tell, this month (September 2021), I recreated all my Smart Lighting routines using Automations. Every automation not using a custom DTM is running locally. (Custom device handlers still require the cloud, which is the same as for Smart Lighting).
So I think the current advice would be “If you can solve your need via Automations, then do it via Automations”.
Up to a point. I personally would note that Automations are very much pitched as a feature of the mobile apps and don’t merit a mention in the developer documentation. They are a tool for app users and I think once you grow beyond the confines of the mobile app you should definitely be thinking in terms of Rules and not Automations. Although my only remaining legacy based app/automation is the ActionTiles connector, I make minimal use of Automations. Indeed I use them for three reasons:
My main reasons for avoiding them like the plague:
However the more general principle remains. Don’t add anything legacy based unless you are confident it isn’t a dead end.