Are there performance benefits to turning off archivelogging? Is it wise

Benefits of Packages

Logical Grouping – Methods that work together can be put into a cohesive unit rather than just logically coupled but physically separate.

Secure Private Methods - Functions and Procedures can be made private to the package and only be used within it. This makes the public surface simpler and more secure.

Privilege Management – Permissions can be granted once for a group of procedures that work together rather than separately for each procedure/function required.

Secure Wrapping - Wrapped packages are more difficult to unwrap than wrapped functions/procedures.

Simplified Naming – A larger namespace allows names that are simpler and can be re-used in other packages.

Better Performance – Packages can be compiled and are loaded into memory in entirety rather than piecemeal as other methods. This benefit if it exists at all is minimal compared to the other benefits.

Reduced Invalidation – Changing a package body does not invalidate dependencies as changing a function or procedure does.

Unique Features - Package Variables, Package Constants, Initialization, Session State, Package Comments, and Overloaded Methods.

References:
11.2 Concepts Guide
Ask Tom Question
StackOverflow.com Question on Package Performance
Unwrapping PL/SQL Presentation (pdf)

Yes, the benefit comes when you want to query on a part of the index. If you put the part-used predicates first the index can be used for queries that involve those predicates but not all of the columns in the index.

Also, unless you have other requirements it can help to put the most selective predicates first, as this can trim down index seek operations faster.

In your case IDX_2 is not necessarily redundant depending on the nature of the queries on the table. However, it may not be necessary to include all of the columns. If, for example, you do a lot of queries by location and date then IDX_2 may be useful to help resolve those queries as IDX_1 is not in the right order to be useful for that. You might, however, find that item is redundant on IDX_2.

From 9i, Oracle introduced a 'skip scan' operator where trailing index columns can be queried more efficiently, which can reduce the need for supplementary indexes of this sort.

In a more specific case, if you are querying item by location and date and don't need any other columns then the query could be completely resolved though the index without having to read anything from the table. You can also build covering indexes that have non-indexed columns attached. If all of the needed columns can be resolved from the covering index the query doesn't need to touch the main table at all.

Finally, in answer to your last question: If you have a set of regularly used queries that are using up a lot of resources and could be tuned using an index then it's certainly worth considering. However, maintaining indexes comes with an overhead on inserts, so you will have to trade query performance off against the overhead that the indexes place on insert or update operations.