That’s true, but it is not an error. In that example vlan 1 is not used for user data (other than possibly by the router for spanning tree protocol). It isn’t used as a layer 3 interface with an ip address applied.
Specifically there is no /interface bridge vlan line that mentions vlan 1. Only 10, 20, and 30 and 99 in the router.rsc file. And 99 was for management.
I don’t understand why @pcunite used the term BASE_VLAN for the vlan 99 interface. He says in his article
Native, Base, & MGMT (management) VLAN:
Before designing IP Addressing & Routing, you’ll need to choose a VLAN scheme. To get your VLAN going you have to start somewhere and that’s usually something termed the Native VLAN. This would be the base network that you used to initiate your first connection to a router or switch. The Native VLAN is not a requirement but rather something that continues to exist if you allow it. Think of the Native VLAN as a term used to describe packets without a VLAN tag that move between your equipment and network. Whether or not this is a good thing is up to you. In our examples, we do not allow for this scenario. Instead we implement a Base VLAN (our name for the management VLAN). Over this network will be device to device traffic (routing, etc.). We also default Winbox availability here as well.
I tend to use the term Base as the interface that you create a vlan subinterface under; when using the vlan-filtering bridge this will usually be the bridge interface (which is nameed BR1) in your config. vlan interfaces are logical interfaces that behave a separate L3 interfaces that you can apply an ip address, but there is a shim between the the logical interface an the physical port that adds a vlan tag on egress and when a tagged frame is received the physical port driver removes the tag and forwards the untagged ethernet payload to the correct vlan interface.
I could go into more details about this, but the advice that @k6ccc and @anav gave to avoid using vlan 1 for any user data (including management) is good advice. There are multiple reasons, but they all usually boil down to the fact that vlan 1 is the vlan that will be used in the default case.
The pcunite thread is a great starting point, but it is more of a user guide than a reference that explains things in detail. My first MikroTik router was a hEX S (RB760iGS) and my previous vlan explosure was from a vyatta/EdgeOS (specifically the Ubiquiti ER-X which is based on the same MediaTek MT7621 SoC as the hEX) and Cisco/IOS vlan and various vlan-aware switches (MikroTik SwOS based CSS106-5G-1S, TP-Link Tl-SG108E and TL-2008v3 , NetGear GS908E, and several Cisco switches). @Sindy’s thread RouterOS bridge mysteries explained was very helpful to me. If you are interested in learning more about what the bridge in the hEX represents, that is worth reading, and I have some notes about it here and the post that follows. But I like to understand why things work, some people are more interested in just getting a working config (and understanding why it works is of no interest to them). So you may or may not find it of interest.
MikroTik also has reasonably good documentation here, which should be understandable if you have worked with vlans on another vendor’s kit. Bridging and Switching - Bridge VLAN Filtering and Bridging and Switching Case Studies - Bridge VLAN Table And you should at least skim what is in Bridging and Switching
Don’t be too put off by @anav. He has a standard way to configure things that works well, and if you don’t want to accept his way of doing it, he won’t continue to help. You may want to review his New User Pathway To Config Success. It is relatively well organized (for what can be done in a forum post), and he has sections on a variety of configuration topics. It is well worth skimming it; you will probably find some useful info there. His style can be off-putting, and his avatar is appropriate, so be prepared for some flames.