I assume your coding practices are contained in the bullet list. As a comparison. The tcl coding practices are many pages in length and contain actual examples of good and bad style.
Mostly the bullets are way to general to be useful. But lets start by combining a few of your bullets. Are the formbuilder procs and the usage of the wrapper ad_form documented enough to require their usage?
Also, my long standing complaint about ad_form is that it encourages mixing html with the tcl pages, making it difficult to maintain code once it goes into a client project. I know folks are going to shout me down one more time on this, but when you put html attributes into the tcl page, that 'is' html code. Just because the '<' and '>' are not on the page doesn't mean you have removed html coding, thus presentation, from the tcl page. So one thing missing in 'use ad_form' is 'how to use ad_form', which I believe can be used in the way I am suggesting, but seldom is used that way.
Overall though, I don't understand the requirement to use ad_form and listbuilder. These are big complex tools that make the OpenACS toolkit more difficult to understand for new users. In contrast the db_* procedures simplify life. You don't need a rule to get folks to use them because you can understand them, most of the time, pretty quickly.
Code review: who can complain about that? Question: how do you determine that an api is 'unused'?
Your last idea of moving table/index apart from pl sounds good initially, but really in a lot of cases it isn't necessary. Indexes do have to be recreated if you make datamodel changes, maybe they should be separate from tables? Personally I haven't run into any problems in this area.
And what exactly is specific about 'document code'? I thought code was documentation. Documentation isn't needed until something doesn't work like you expect. Then you really need it. Chances are, the person who wrote the code understands the limitations and never ran into the problem, so it isn't documented anyway. Bottom line is that what the code writer thinks of as documentation might not be enough for the casual user. Better than just documenting code is to write it so it is easy to understand. We have a toolkit filled with procs that go on page after page. If this code was broken down into more understandable chunks it might be easier to figure on the occasion it doesn't work the way you think it should. You could also try using meaningful variable names. Also, not overloading a variable with several usages in a proc helps a lot in figuring out what a proc does.
I know I have a bunch of dumb ideas and views. I assume folks will question them. That is a good thing. Sorry to digress.
