Originally my altered Low Level category rule looked like this:
However, while I was trying to figure out why it wasn't working as intended I simplified it to this, which apparently (with my modification to the function) produces the same result:
I'm not sure why that works. My original rule might have been too pedantic because there are things I don't understand about LUA or the ESO API.

I've been willing to endure the "lag" you describe (which really isn't lag in the correct sense) because being able to categorize everything is crucial to me, but your complaint is not invalid. If one were to take AutoCategory and strip out all the custom programmability and leave just a one-size-fits-all cookie-cutter version, it might result in reduced computational burden that would please you. I wouldn't find any use for that one-size-fits-all version, though. The time it saves me in making sense of virtual containers full of hundreds of virtual items - once I've been able to customize it to my workflow and way of visualizing things - is well worth the extra seconds I wait for transactions to finish.
.

I have been happy to use autocategory. But as soon as I began dealing with guild banks I had to stop. The performance degradation is simply to bad. It's literally like 500% increase in time spent waiting, and when opening the guild bank if there is more than 300 items in there it's just horrid. Not to mentioned actually withdrawing and depositing has severe lag on each item.

I really like the categories, but there is something wrong and/or very inefficient about how this addon works. I wish I knew how to code well so I could fix this myself, but unfortunately I will be stuck with the vanilla mess of a long scrolling list; but at least it has good performance.

Post your current rule code here and I will take a look

I don't know how to do that, if it's possible and not overly cumbersome.

As long as what it does is documented in the wiki, I don't think the function name need be confusing. As I discovered, returning the actual or even effective character CP value has no use at all for any category matching, period, so why not massage what's returned to suit the purpose, as long as it's documented? Surely doing so in an LUA function directly is more efficient than in a parsed and exec'd string?

It doesn't occur for me, and I have many dozens of mods installed. I thought it was odd to declare such a showstopper issue without any further detail. I did, however, have the guild bank frame hang/freeze earlier today when I was experimenting with a category rule, and a bunch of LUA error detail was dumped into the chat frame rather than the usual notification. Is it possible to craft a category rule that when parsed and exec'd could crash the game? That would be quite the exploit.

I cannot reproduce this with any of my guilds, can you give me any more information? Anyone else able to confirm or deny this?

It doesn't really make sense to have a "CharCP" function that returns something besides the actual character CP. Why not build the logic into your custom filter rule?

When I asked for the inclusion of the charcp() function, I was guilty of poor conceptualization. You added the function as I drafted it, but it doesn't work as I intended because I screwed up. What it now returns is the actual character's CP, but if that value is higher than 160 then it becomes useless in tests against gear levels and instead results in erroneous matches. I didn't catch this sooner because I didn't have enough variety of stored gear.

The function needed a test to set a ceiling of 160 on the value that it returns. I have corrected the function locally, but could you add this correction to the next update so that it carries forward?
If there's a more efficient way of coding that by embedding the test directly into the declaration for cp, you're welcome to do it.

Illuminating!

Currently this addon crashes my game when I open the guild bank.

Can you give me examples of sets that are not picked up by the autoset() filter? I've never seen this, and I can't see why it would happen. Are you sure the items in question aren't being grouped into a higher priority filter?

I'd like to create a custom Clothing category. It's a subset of Low Level, since the item level is always 1. However, to do that and distinguish it from actual level 1 armor, I'd need a new function to test and return the armor value of an item, since the absence of an armor value is what sets clothing apart from other level 1 gear.

Is adding a function armorvalue() possible? I can't find an API call that would return it, but I assume that it must exist.

Ta for advice. Might not have made myself clear. I kept all that you advised me to do; only replaced the first part (the "inset" for "autoset" - because I like to see the items grouped under their relevant 'set'.) All my non-50/160 items that show set details remain in the more general categories.

If you encounter any gear that isn't level 50 + CP 160, it will match that rule and appear in your Sets category. The very first criteria in your post was that only CP160 gear should appear in that category. If you truly meant that, then you must add at least something like "and cp() >= 160" to make the rule satisfy your criteria.

I swapped "inset()" for "autoset()" and it seems to work like a charm - thank you for quick and informative response - cheers