$ for non-jQuery utility functions. Why not use the company's own namespace? If you need to be concise, use $$ etc.The native prototypes debate is a bit tired, there are valid points on both sides, I'll try to summarize them in hope it might be useful to see the big picture.
contra There's no need to extend native prototypes. You've got everything you need.
pro JS standard library is scarce to the extreme. Arrays and strings are lacking many vital features.
contra Use functions or your own "namespaces".
pro Methods like foo.trim() are far more in the spirit of the language than functions like org.blah.trim(foo). Everything is object in javascript and let it be that way.
contra Native JS objects are "reserved" for the language designers. Our methods can accidentally override newly added built-ins.
pro Open objects is a great feature and it would be silly not to use it. A new Javascript version is not something that happens every day and additions to the standard are well known in advance.
contra Extending native prototypes is confusing, because there's no distinction between our and native methods.
pro JS standard library is small and well documented. We javascript developers are supposed to know native methods' names.
contra Extending prototypes can lead to namespace conflicts.
pro Yes, but this can happen with global functions or well-known global objects (like $) as well.
contra Custom methods are enumerable.
pro Yes, but there's hasOwnProperty to the rescue. Wrap it in your own enumerator function and stop using raw for..in loops with objects.
(not a real answer, hence CW)
I think it's not stupid!, But It's more beautiful to use prototype!, But then again who cares about beauty? Your code eventually will be scary and will suck, But if it's well documented and consistent you'll never need to think about these issues!