I feel your pain on security... welcome to the wonderful world of prosumer equipment.
(Actually I work mostly with enterprise-grade equipment, and while it is much more secure, sometimes even there, there are some surprising features missing... at least surprising to anyone who actually cares to secure things at the network level.)
The issue of vendors compromising client devices is not very new... the same issues exist with your web browser offering a possible back door into your PC... and it has taken quite some work over the years for browser developers to develop and implement a security model.
The difference is that IoT is still in the wild west stage. In analogous browser terms they are just about moving from MOSAIC to NetScape and maybe thinking about implementing https.
Playing with the switch config is pretty treacherous... you can lock things up pretty badly if you do it wrong and have to go back to failsafe mode or even reflash depending on what platform you are working on. First get it working from the cli using one of the switch control packages (these days there is a legacy and an iproute2 version of just about all network cli tools). That way you can just reboot to fix things.
It's actually really simple and I don't know why it ends up being so hard to explain:
Each switch has one internal ID for each VLAN. This ID is not necessarily the same as the VLAN tag as it appears on the wire. Each "switch_vlan" statement is one of those internal IDs. The "vlan" option in this section says what the outside-world VLAN tag is for this internal ID. LEDE config files never show you the internal vlan ID.
Each switch has a connection to the CPU. From the perspective of the switch this is just another port (just without a jack). From the perspective of the CPU, this is a network card. Each "switch" statement is one of those. The network device seen by the CPU is the name of the "switch" section. We will assume for now you only have one switch.
Each port, including the fake one attached to the CPU has an internal number on the switch (some switches start at 1, some start at 0). Knowing which port number is the CPU is important. Also, knowing which number is the interface you are logging in with is important. Knowing that there is an extra "fake" CPU port that (for your purposes) goes nowhere on a lot of models can also come in handy. The numbers do not always match numbers printed on the plastic.
The WAN port is usually not part of the switch. It is seen by the CPU as another network card.
From among your switch_vlan statements, each port, including the fake one that connects the CPU, can choose one "untagged" VLAN and as many "tagged" vlans as the hardware supports. Ports do not have to carry every VLAN on the switch, so we list which ports are in each VLAN. And we add a "t" if that VLAN is tagged on that port. A port should have a "t" after it in every switch_vlan it appears in except optionally one.
The switch_vlan statement where your CPU port has no "t", if any, determines what VLAN the "ethX" device on the router is talking with. Where "ethX" is the name of the owning "switch" statement.
If the CPU port appears with a 't' after it in a switch VLAN, you can create a vlan interface on the router. We usually name these "ethX.Y" where Y is the actual VLAN tag (we pretend the switch's internal VLAN IDs and internal port IDs do not exist; they are useless outside the switch). This interface can talk with that VLAN.
If a port is listed without a "t" it now has to deal with a small problem: it is sending packets from one VLAN without a tag on them. It expects replies to those packets to come back without a tag attached. But what does it do if it gets a packet that IS tagged and the tag is the same VLAN as it is sending out without tags? In a sane world, the answer would be that there is a flag that decides whether to ignore those packets, or alternatively, just pretend they didn't have a tag, but since networkers will make anything more complicated just to allow for weird use cases, instead what they did was give you this "pvid" value, which requires you to manually tell the switch what to do with packets that have NO tag, and on prosumer gear they do NOT give you the option of ignoring tagged packets. Jut set the PVID to the VLAN tag of the switch_vlan stateent where the port appears without a 't' after it.
Keep everything neatly ordered if you are gong to use LUCI to set up the switch. Some of the LUCI scripts can screw things up royally if things are out of order to start with.
For best security, don't use untagged VLANs on your backbone wired links or links to servers that have to be on multiple VLANs, to prevent QinQ tag hopping attack vectors. Only use them alone, for clients. Note that WiFi has no (functional) VLAN tag, hostapd emulates that, so you don't have to worry there.
You can see the port numbers for your switch by looking for its model string in /etc/board.d/02_network, and hoping it is right for your particular device. Some models even have the numbers printed on the plastic mapped there so UIs can make use of them. If the plastic numbers do not appear, it could mean they match the switch numbers, or it could mean nobody has bothered to flll them out since that feature was added.
You can apply IP addresses to the ethX or ethX.Y interfaces directly, but usually, you join them to a bridge and apply the IP to the br interface. That allows you to put wifi clients on the vlan.
So for admin purposes, if you must admin from Wifi, the best thing is to get your admin device locked to a particular IP, then allow packets to go through the AP, to the router, through a pinhole for that IP in the firewall, and onto the backbone, where you are letting LUCI listen on the APs.
Locking IPs can be done by giving them a special lease in the DHCP server configuration.
Making sure that devices do not steal your IP can be done by adding firewall/bridge-firewall rules to only allow that IP to be used from your MAC address. (Which is why when I started playing with LEDE one of the first things I did was make packaging for ebtables-dhcsnooping to do so automatically for all clients.)
Making sure nobody steals your MAC address when you are not around (or through another AP) requires running WPA-enterprise and doing crazy stuff with FreeRADIUS, not to mention rolling your own mini-PKI.
TLDR: running a truly secure wifi network is really friggin hard, and you cannot buy your way out of the pain with prosumer gear, and the only thing enterprise gear does is move half of that pain to your wallet.
also TLDR from my first post: WPA2-PSK is inherently insecure unless you trust all your clients not to mess with each other (per SSID). IoT clients cannot be trusted for reasons you stated beautifully, and most only do WPA-PSK/2.4GHz. You only have so many SSIDs to burn on 2.4GHz. Ergo, IoT wifi junk is utter crap for security (and wired is junk too, given prosumer wired switch feature sets.)
Obviously, to sit here and write this, I am waaaaaayyyy too bored tonight.