O(1), which basically means they take the exact same (constant) time, as far as you should be concerned with creating one variable with them.
Changing them would be O(1) again for boolean, number, string (even if it uses a hash table, that's still a non-issue), and it'd be O(2) for tables because of one extra access... which is still constant, so O(1).

In 64 bit system, performance of any integer operations up to 64 bits in length is constant, since that's a size of one register and the processor would normally be optimized to handle the whole thing in one go, therefore there is no performance gain to be had from only using a fraction of it. X86 and derivatives usually have very fast floating point unit, simple float operations are usually as fast as simple integer operations. Complex operations performance may vary; it is always slower, however as far as practical evidence goes, complex floating point math is substantially faster than equivalent integer math. There is no difference between single and double precision computation performance, both are internally converted to at least 80 bits floating point numbers, possibly more depending on processor model. ARM processors is a bit different story, they suffer noticeably from using double precision numbers and their floating point unit is in general not as advanced. There is also cache hit rate to be considered, but in context of Lua that can not really be managed beyond using consecutive integer keys in the same array during data grinding.

Lua strings are byte arrays accompanied by length indicator variable. Whenever string needs to be created, pool of existing strings is checked and reference to existing string is returned if it's there, otherwise new byte string is created. String equality check is therefore O(1) and at that is extremely fast, but dynamic string management may have substantial overhead.

Lua tables are comprised of two parts: array part and hash part. All integer keyed values that the table deems worth resizing the array part for go into array part, everything else goes to hash part. Access complexity is always O(1) but keys from array part are indexed faster since there is no hash evaluation. Every time you use brackets construct a new table is created, if you let go of it e.g. by using it as a transient container, it becomes garbage and contributes to GC overhead. Same goes for temporarily existing strings.

In short, all of your examples should take about the same time during execution except for:
which allocates a new table and that is always slower.
If "variable" is global then you have "global assignment" which is slower compared to using locals.

Like raidho36 said, literal values are handled quite fast, as opposed to string operations (string., "..", or table.concat).