[dba-SQLServer]Architecture/how to do it advice

This seems to be a good collection of people with wide experience, so I'd
like to ask a strategy type question.  I don't have any certifications, but
am reasonably experienced in vb, access and now sql server 2000.  Nothing on
too large a scale, but what I've built is a sophisticated app for a brewery
to track and evaluate production and r&d.  I've done my reading and have
tried to incorporate what I understand to be good practices (good quality
code, copious sprocs, udfs where appropriate, good security...)

I am in the middle of porting much of the reporting part of the app to the
web (an intranet) to make it more easily available to users.  I have hired
an outside consultant to help with much of it.  He is not a db guy, so is
most comfortable with opening connections as needed on an asp page, sending
a query string over the network, etc.  We argue constantly about many
aspects of architecture, for example the use of sprocs (he doesn't see the
need for them, doesn't understand their advantages, knows only that he can't
see them) in spite of me trying to explain the advantages, some of which are
not relevant to our situation (we are unlikely to suffer an sql injection
attack).  However I am of the opinion that forming good habits is essential,
because sooner or later it will become important that something be done the
'right' way, and if it is a habit you won't have to stop and think about it.

The real point of this message is:  he described to me another project he is
working on for a major state agency that will be web based.  As he described
it, each time a user opens the app there are 500 round trips across the
server, each to fire a separate stored procedure or execute an sql string.
Each time, for each user!  This has been architected by people who at least
locally (and I also suspect on a statewide level) have reputations for being
expert, professional and experienced (oracle guys).  I was stunned.  So my
questions are:  I don't have experience with lots of different companies, or
with meeting strict deadlines -- do I need to lighten up?  I think some of
the reasons for their approach was that they had time constraints (you know,
never enough time to do it right...).  

I don't mean to start people off on rants (for or against).  But should I be
sticking to my guns? D. Lewis