Fully agree with Joe here - Boolean is basically nothing other than a short cut to something you could do better by proper modelling techniques and a bit of planning. Holes? Make the hole and build the mesh around it.
In the vast majority of cases, yes, you could get a nicer result by using something other than booleans.
However, I don’t think everyone realizes WHY booleans are (or at least can be) bad. And for amateur/hobbyists, those reasons may not apply. But as a general work practice, professionals don’t like them for the reasons I mentioned, plus a bunch more.
One reason is because you can easily generate polygons that can cause troubles, either in your own app, or when exporting to another app. It might surprise some here, but not all apps handle polygons the same way. How they handle them can vary, and there’s no “right” way. It can involve some tradeoffs or design decisions.
For example, if your modelling generates n-gons, such as with 3DAge’s method of drawing out and extruding the faceplate with holes in it, you could have problems. Some apps don’t accept n-gons on import, such as Carrara. It converts n-gons to triangles. So you can make a nice looking shape in one app, and when it gets to the other you get a trashy mess of weird triangles. Good modelling practice? Well, not much you can do. And handling n-gons is often fraught with other problems. How do you subdivide them? Some algorithms required quads for subdivision. What they gonna do with an n-gon?
So whether you generate n-gons with boolean operations, or with a “draw out and extrude” operation, you could have the exact same problems.
Booleans can also cause non-planar polygons that don’t render correctly in some apps. A triangle can’t be non-planar, but any polygon with 4 or more vertices (including n-gons) can be. So whether you generate a non-planar n-gon with booleans or with extruded spline modelling or whatever, you could have problems. If you have a quad polygon with 4 vertices, and you move any one of those vertices a micro-meter away from planar, you have a non-planar polygon. So what happens if you move two opposing vertices of the quad poly to form a sort of inverted V? How does the program and renderer handle it? Should it convert the quad to two tris like some apps do? Or should it just not render the poly and leave a black hole, like Blender and Lightwave and others do (if I’m remembering my apps correctly). There’s no “right” answer. Now with an n-gon with 36 vertices, you have a whole lot more chances to make that a non-planar polygon, and what is the program gonna do with that mess when you start moving vertices? Probably why Carrara converts n-gons to tris, to get rid of the hassle.
Which is why I start just about all of my modelling with a primitive box (“box modelling”) and modify from there. You know you have clean, planar, uniform polygons, and you just make sure you apply clean operations that don’t generate bad stuff along the way. Anything else you do leaves you open to generating bad polygons, which may or may not cause problems depending on what you do with them.
I guess the point is, boolean operations themselves aren’t bad, it’s what they generate that can be bad. So if you’re generating the same stuff using other techniques, it’s still bad. Or at least can be bad, depending. But there are cases where you’re not gonna generate an ideal mesh no matter how you handle it.
By the way, Roy, I’m fascinated by your idea of making a hole and building a mesh around it. I assume that was a joke, or do you have a cool modelling technique?