capability and performance of tags implemented as array vs text vs full text
You can get search functionality with arrays by using the ANY/SOME or generate_subscripts functions. However, the PostgreSQL documentation notes the following:


  Tip: Arrays are not sets; searching for specific array elements can be a sign of database misdesign. Consider using a separate table with a row for each item that would be an array element. This will be easier to search, and is likely to scale better for a large number of elements.


So it looks like you're on the right track, because you're correct about not losing performance (you would more likely gain it) and the other methods allow greater flexibility. Tags themselves are about exact matches, but most sites have a way to search tags too (for instance, this very site). 

If you implement tag storage as full text, that doesn't preclude matching, including regex, with simpler expressions such as LIKE/ILIKE. A common scenario is to store documents (the chunks of text being searched) as text or varying character and store the tsvector type necessary for full-text search in a separate column. See the PostgreSQL documentation for more on creating a full text index.

The pros and cons should then be evident: using an array limits scalability and search options because it lacks text indexing, stemming and inflection support, but is easy to use when an exact match is desired. Using a text datatype is more flexible when searching for strings. Using a text datatype with a generated tsvector column provides the most flexibility and good performance in all scenarios, but requires more storage.