Question: Recently, I read a lot of good articles about how to do good encapsulation. And when I say "good encapsulation", I am not talking about hiding private fields with public properties; I am talking about preventing users of your API from doing wrong things.

Here are two good articles about this subject:

<http://blog.ploeh.dk/2011/05/24/PokayokeDesignFromSmellToFragrance.aspx>

<http://lostechies.com/derickbailey/2011/03/28/encapsulation-youre-doing-it-wrong/>

At my job, the majority of our applications are not destined for other programmers but rather for the customers.

About 80% of the application code is at the top of the structure (Not used by other code). For this reason, there is probably no chance ever that this code will be used by other application. 

An example of encapsulation that prevents users from doing wrong things with your API is returning an IEnumerable instead of IList when you don't want to give the ability to the user to add or remove items in the list.

My question is: When can encapsulation be considered simply OOP purism, keeping in mind that each hour of programming is charged to the customer?

I want to create code that is maintainable and easy to read and use, but when I am not building a public API (to be used by other programmers), where can we draw the line between perfect code and not so perfect code?

Answer: 
The fact that your code is not being written as a public API is not really the point--the maintainability you mention is.

Yes, application development is a cost center, and the customer does not want to pay for unnecessary work. However, a badly designed or implemented application is going to cost the customer a lot more money when they decide that it needs another feature, or (as will certainly happen) the business rules change. Good OO principles are there because they help make it safer to modify and append the code base.

So, the customer may not directly care what your code looks like, but the next guy who has to modify it certainly will. If the encapsulation (as you're defining it) is not there, it's going to take him a lot longer and be much riskier for him to do what he needs to do to serve the customer's needs.
Encapsulation exists to protect your class invariants. This is the primary measure for 'how much is enough'. Any way to break invariants breaks class semantics and is bad (tm).

A secondary concern is limiting visibility and as such the number of places that can/will access data and thus increase coupling and/or number of dependencies. This needs to be done with care though. As requirements change, often times that decision to limit what the class exposes leads to awkward hacks to deal with the new requirement.

This though is one of those design concerns that comes with experience. In doubt, favor encapsulation. The concerns are regardless of 'public' API or not. Even for internal code, new or forgetful or sleepy programmers *will* write bad code. If your class needs to be resistant to bad code, then do so.