If by 'Cowboy Coding' you're meaning freeform development without a rigid structure, YES, much of my coding fits into this category.
I do a lot of greenfield development and research, which means I'm constantly opening up my editor to a blank file, working, and later throwing away my result (I don't keep working in it).
Much of my client work is on a consultation basis as well, so rather than being a part of their internal structure (if there is one) I'm expected to be self-driven, self-organizing, and get the work done without them having to worry about it.
The term 'cowboy coding' usually only refers to programmers who do risky things, ignoring best practices though:
But I think I can list some advantages of 'freeform development' that might get missed in the 'cowboy coding' connotation:
Free to explore: this is excellent when the problem domain is unknown. When you begin with a structure and you don't yet know the shape if what needs to be built, it's hard to argue that approaching an unknown problem with a partial solution isn't a case of 'premature optimization' that might turn into technical debt if you gamble wrong, and a different structure ends up suiting the problem better than your starting point.
Free to refactor: similar to exploring the problem domain, once you do understand the shape of the problem it's much easier to refactor the code you have written to suit it. Imagine you are tailoring a garment to a person, is it easier to tailor a brand new garment that's never been altered before, or to adjust a garment that's already been fitted and tailored to a different person? Freeform development lets you keep things loose until you need to tighten them up, then gives you the freedom you need to do it well
Free to throw away: I think at least for me, the amount if disposable code I generate versus the amount of code I hang onto is key for reaching the quality level I desire in the code I hang onto. If I was working within a structure that made it more difficult to throw away code, I imagine I would be more tempted to polish code that was less-good, rather than throw it out and rewrite the code I actually need. The more structure and process you have, the harder it becomes to write code you intend to throw out as well. You get locked into writing only what you keep, and keeping all you write, and that's not a process that produces the best code all the time.
If this was a chef in the kitchen rather than coding we might call 'cowboy coding' something like 'cooking without a recipe', which sounds a lot better than 'cowboy cooking'. I imagine there are times and places where chefs follow recipes and strict guidelines for what they are making, and there's probably a lot of time spent doing things by feel, exploring, and experiencing what they are cooking that isn't rigidly dictated in advance. Both types are useful, both styles produce good results. It's all about balancing your knowledge with your learning while addressing the task at hand!