Why not? Seems fairly trivial change and it would enhance the usability a lot. For example, this would enable filtering textures by texture size (parallels to #2801) if the size is encoded in the name with a filter like *128*, or dirt*128* if you also want to filter by name and size.
Sure, allowing glob patterns for texture names seems easily doable. To avoid misunderstandings, I don't feel we should extend this to filtering by texture dimensions by encoding the dimensions in the name however.
I mean it would be useful if the size was already mentioned it in the name, not that we should do it ourselves :-)
With glob support, wall doesn't match for textures with wall as part of the name anymore, the glob equivalent for this would be *wall*, which needs more typing, and the change in behaviour would lead to some confusion too. I think some kind of smart detection system for enabling glob support would be needed as well (only enable it when special characters are typed?).
I agreed "wall" should continue to match *wall* as this is the default search/filter behaviour in most software.
Auto-enabling glob patterns is a kind of in-band signalling, and indeed textures starting with "*" is a real thing in Quake (liquids) so it'd be ambiguous whether you were searching for a literal * for a water texture, or a glob *. Maybe a small toggle button / combobox? A lot of text editors do this for enabling regex search.
Visual Studio Code has something similar for enabling Regular Expressions in the search:

Most helpful comment
Sure, allowing glob patterns for texture names seems easily doable. To avoid misunderstandings, I don't feel we should extend this to filtering by texture dimensions by encoding the dimensions in the name however.