I feel like congratulating myself. As I tested my nearly-finished game on the iOS, I realized that just having a few enemies on the screen at once used up a decent 1-4ms of processing time. Not OK, considering there are times when I have 20+ enemies on the screen. During those times, frame rate would drop to 5fps or less. 
So I re-did my EnemyScript today! It took the past 12 hours including stints @ starbucks and a chicken place for dinner, working throughout. On the 3rd try (the first two didn’t work right and weren’t saving enough time), I got it figured out.
Now each enemy takes about 0.04ms per frame about 1% of what it took before!
In the end I relied heavily on the NavMesh, turning it off when not needed (during idle/defense/attack/cast), as well as InvokeRepeating to do things only a couple times per second instead of every frame. Also removed a lot of Vector3.Distance calls and minimized transform.LookAt. In most frames the enemy script isn’t really doing much of anything!
So yoo-hoo for me 
Nice.
Having scripts do as little as possible most of the time is a pretty good way to help performance. I typically design up-front so that my scripts are all doing nothing as much as possible, and I try to avoid using Update(…) et. al. wherever I can.
If you’re familiar with the concept of events, they’re a great way to know when things have changed so that you can have your components react appropriately while being dormant the rest of the time. So even where you do use Update(), the components can be disabled right up until the point where they need to actually do something, at which point they enable themselves, do their thing, and turn themselves off again.
Out of curiosity, what were you doing before that took up a whole 4ms?
Yeah – The past couple days were spent on a lot of small scripts, removing the Update() loop entirely, instead using InvokeRepeating for a lot of things that didn’t need to be every frame, in some cases could really be fine at once every 5 seconds.
I’m not entirely sure what I was doing before. It’s been 10 months since I started this, and I’ve learned a LOT since then. The enemy script was written once at the start, and re-written maybe 6 months ago to add new features like backing up if the player is close, dodging, running away after attacks etc – to make the enemies more realistic.
I think it was a lot of poor logic, a lot of unneeded bits (like looking for player distance every frame – I switched that to assume the player is not close if they haven’t received a ping from the player in 10 seconds, and the player script just does an overlap sphere now), and redundant stuff.
Also before I wasn’t using the NavMeshAgent as I should have been, rather just having the enemy LookAt the player and move forward with a mecanim Root Motion animation. Just not very efficient I guess.
Also, the event system is something I don’t use yet aside for knowing when the player connects or disconnects a gamepad, but it’s in my mind for things like when the player dies.
Fair enough. There’s a lot of hidden gotchas that it could have been, so it may have been something completely counter-intuitive. The important thing is that you got there, though.
One that immediately springs to mind is that moving something with a collider is really expensive unless it also has a Rigidbody. You’d think that having a Rigidbody would make it more expensive, but in some cases it can do the opposite. (It makes perfect sense when you understand how the physics system works, but that’s not something newcomers are expected to know.)
One thing I learned long ago that stumped me for a quite a bit (before I figured out how to use the profiler) is that printing anything to the log takes a ton of frame time. Empty Update() loops are a small issue if there’s a ton of them. Not as noticeable on the computer, but on mobile, it’s crazy. The rigid body is one thing that I never ran into an issue with, since I always had the rigid body attached to things I was moving, but I have seen that warning a bunch of places in the docs.