Is it a good practice? It depends. I do agree that you probably don't want to just send the default page to the user. That spoils usability, and it can provide too much information for an attacker if there are technical details.
However, what about sending 403 errors more generally? Here I am less convinced that it is a bad idea generally, and the larger question is what is going on or why is the 403 error occurring?
If I see a 403 error with a default error page, or particularly when I am not even logged in, this screams "incompetent admin" and therefore might seem to invite attack not so much through what it reveals about your site so much as what it reveals about your administrators.
But suppose I am logged in. I have been authenticated. Is there any reason when I try to access a resource I am not authorized to view that it should return something other than a 403 Access Denied error message? Passing back the error code allows this to be programmatically handled on the client side which is an important consideration with things like web services.
Now obviously this should never happen when you try to do something exposed in the UI. But as an additional layer of defence and opportunity for error handling, I don't see anything wrong with passing back the error code in this case, because there may be causes (again, web services come to mind) where passing the error code is the best way forward.
So with this in mind, I see a few things that have to be looked at non-prejudicially:
What information is leaked that can help an attacker? What information should be provided with the error message?
In general, with LedgerSMB we log extensively, but anything access-denied wise is a very short message on the client-facing side. This enables the admin to see what's going on but not the user.
What does the client minimally need to know in order to handle the error?
Usually, IMO, just that access was denied despite being logged in. The 403 can be helpful here, but you don't want to send much more than this.
What other concerns do you have?
A lot of things are dependent on threat model. The threat model of a customer-facing web application is very different than a line of business web app, and these are different than a subscription web service. You need to know what you are protecting and from what before you go further.