I've always advocated checking in regularly (i.e. more than once a day), but only checking in code that compiles. Even if a feature isn't 100% complete, it provides earlier oportunities to determine if the work in progress is going to affect other parts of the code.
Here's an example of what your company is (hopefully) trying to avoid:
Many moons ago, I had a borrowed developer working on an IR&D project. Despite me badgering him to check his code in every day for a month he wouldn't do it. When he finally did check in the code it was working as long as there was only ever one user at a time. By developing a Java web application like a C project (everything was a static method, aka function) he caused a whole mess of rework for the rest of the team.
There are similar horror stories such as the original IR&D developer not using version control at all, and the current version of the software was in his local directory on his machine instead of the file server. He left the company, leaving the IR&D project high and dry (which is why I was brought in and dealt with the situation above).
That said, I'd rather know that there are issues and design choices that need to be addressed earlier rather than later. However, the trunk should always compile. I've never left for the day with a broken build. Whatever your solution, keep in mind the cautionary tale of the developer who wouldn't check in code, but also keep in mind the horror of the first person arriving for the day having to fix everyone's code before they can continue.
As with all things, there needs to be a healthy balance.
Edit If you ever do find yourself "blessed" with a developer who refuses to check in code for an extended period of time, you have some other problems that you need to resolve. If they refuse to check in their code, insist on a code review--you need some assurance that the code is going to function in your environment when it finally is. If they refuse that, they probably shouldn't be on your project at all.