Things don't have to be complicated or pretty to be fast or good. For a UTF-8 or ASCII (English) string:

  for(char c in string)
    if(c & 1 == 0)
      continue;
    switch(c & 0x1F)
      case(a & 0x1F)
        return true; //a or A
      case(e & 0x1F)
        return true; //e or E
      case(i & 0x1F)
        return true; //i or I
      case(o & 0x1F)
        return true; //o or O
      case(u & 0x1F)
        return true; //u or U
      default
        continue;

Checking for consonants is about as free as it gets. 50-70% of characters in English text are consonants. By checking one bit, you can eliminate that many checks across the whole string. This should also more or less apply to any text encoding; this technique comes from an artifact of the alphabet itself. It just so happens that all English vowels (including Y and W) fall on odd indices within the alphabet.

Characters aren't magic! They're just numbers. You can do math and binary tricks on them just like you would with any other primitive type. Instead of thinking about finding letters within a string, sometimes you get better answers by asking "how do I find one of a set of numbers within this array of numbers?". It seems to me that a lot of programmers consider these to be entirely disjoint problems. But then again, I'm an embedded programmer and as far as I'm concerned characters are only ever 8 bits wide. String problems are numeric problems for me.

While I don't want to discourage people from exploring problem spaces, do understand that the problem space of ASCII has been trodden to the bedrock. Many problems like "does this string contain a vowel" have been optimally solved for decades. Your explorations should include looking at how we solved these problems in the 20th century, because those solutions are likely still extremely relevant.