Data partition in AX 2012 and why?

Why? - Data partitioning enables us to logically separate all the business data (very few System data, like batch framework and AIF data are shared). With partitions we achieve the isolation of business data, partition specific, with in the same installation of Microsoft Dynamics AX. The business data can be still shared among companies/legal entities that are in the same partition. Microsoft Dynamics AX displays the partition key in the title bar of the client application.

Quick Tip: If utilized properly, partitions can help use maintain two systems, for example, test and UAT in the same environment. We can create one partition for Test and another for UAT and provide access only to the Super users / Customers.
This will help in utilizing the System resources more effectively and reduce unnecessary hardware costs.

Pros and Cons to have Partitions in Production environments:
For a production environment, if the Customer demands to completely isolate the data between two subsidiaries (or geographic locations). This can be achieved using partitions.

General suggestions show that partitioning is not advisable in most of the cases. Instead other approaches are suggested like, Updated security roles with access to specific legal entities, XDS policy implementation, closing cross-company creep holes could be the approach.

Cons in more detail:

• There will be general overhead/inconvenience with running partitions for anyone administering the implementation, like checking batch jobs in different partitions. Also a result could be that there is significant increase of Admin work, maybe by 50-75%. 
• In most real world scenarios, we tend to encounter a business scenario where we will have to try and find mechanisms to share data anyway. 
• There is a significant risk that people might forgot to do the replication of setup and tasks with multiple partitions in place.
• When you create a legal entity, the system assigns it to the current partition. And the legal entity can never be moved to another partition. However, its data can be exported using DIXF, MDM, Excel Addins, Default import export or other data transfer mechanisms. 
• A typical user has authorization in only one partition. However, some users might be authorized to see data in more than one partition. For an example, System administrators are authorized to see data in all partitions.
• Default BI Analysis (SSAS) will be specific to partition and needs additional configuration for each partition.
• The crossCompany keyword will apply only to the companies that are in the same partition.
• A user who plans to work on multiple partitions, if any. When you start the AX32.exe client, your session is assigned to one partition context for that whole session. You can switch to another partition only by starting a new client session.
  Even for System Administrators, they would need separate clients for each partition.
• For every new partition, the system adds one legal entity DAT. And each DAT company in different partition is a separate company from the others and cannot be deleted.

Hardware details:

• Data partitions do not create separate installations of Microsoft Dynamics AX. Partitioned systems share instances of AOS, databases, AOT, administration functionality, AIF, and the batch framework, SSRS, MR.
• However, partitioned systems demands to maintain separate application data, organizational hierarchies, and user configurations.

Quick tip: With Partitions enabled you might have to log on to different client sessions. So you can mention "partition parameter" at run to dynamically open sessions with specific partitions.
Open Windows run, type:
ax32 -partition=nameofpartition

Data partitioning architecture - TechNet link.

Scope of Data Isolation:
Consider the following characteristics of partitioned systems:

1. Shared AOS – A partitioned system is created in the context of a single instance of AOS or an AOS cluster. When Microsoft Dynamics AX is first set up, the system creates a default partition. The partition key for the default partition is "initial". Additional partitions can be created during installation or upgrade, or at any time after the system is deployed. After a partition has been created, it cannot be deleted.
2. Shared database – In a partitioned system, all data is stored in the same database or database cluster. Partitions provide only logical data separation. No physical isolation of data occurs. Many system tables are shared tables that do not contain a column for the partition ID.
3. Shared AOT – A partitioned system has one Microsoft Dynamics AX Application Object Tree (AOT). Customizations are always shared across all partitions. The model store database is not partitioned. Metadata that describes objects in the AOT is shared. Custom code is shared across the system.
4. By default, code runs in the context of the partition for the current session. This behavior resembles the behavior of X++, which handles companies by using the dataAreaId field. Therefore, pre-existing code that uses the X++ query mechanism works without modification. Direct SQL calls must be modified to filter on the context of the current partition.For more information about using data partitions in development projects, see Partitions, Companies, and Data Isolation in Microsoft Dynamics AX.
5. The Microsoft Dynamics AX cross-reference system is shared. Role definitions are shared across the system. In Microsoft Dynamics AX 2012 R2 and later versions, multi-partition configurations have no new requirements to define or maintain reports.
6. Common administration – Users who have the system administrator role can access data in all partitions. However, to view data in a particular partition, the administrator must log on to a client instance for that partition. System administrators can create new partitions. Both system administrators and security administrators can manage users in the context of a partition. License keys and configuration keys are shared across the system.
7. Common application integration – In a partitioned system, Services and Application Integration Framework (AIF) is a shared subsystem. To guarantee that incoming requests are correctly isolated, you can restrict an inbound integration port to a particular partition. Additionally, you can specify a target partition for an incoming request by including the partition key in an XML element in the header of the document. Similarly, outbound responses indicate the source partition for the response data by including the partition key in the header. Because AIF uses a single gateway queue, a system administrator can view all documents in the queue, AIF history, or exceptions list in any partition. The forms that display these lists now have a field that shows the partition key for each document.
8. Common batch framework – Like AIF, the batch processing framework is a shared subsystem. One batch server is shared across partitions. However, each batch job is associated with a specific partition. The batch server executes batch jobs in the context of the correct partition. To view batch jobs or their history, you must log on to the partition that the batch jobs are associated with.
9. Separate application data – Access to application data is controlled by a combination of the partition ID and the user's role and permissions. The Microsoft Dynamics AX client does not let users view unified data across partitions. Microsoft Dynamics AX does not provide a query mechanism to retrieve and combine data from multiple partitions.
10. Separate organizational hierarchies – Each partition contains its own organizational hierarchy, which includes one or more legal entities. Like a new deployment of Microsoft Dynamics AX, each partition that is created contains the DAT company as a default legal entity. System administrators can add legal entities to each partition. Legal entities are never shared between partitions, even if the legal entities have the same name.
11. Separate user configurations – Each partition contains its own list of authorized users. The system administrator who created the partition is automatically created as a user who has the system administrator role in the new partition. After a system administrator logs on to a partition, he or she can add authorized users to the partition. A user can be authorized to access data in more than one partition. However, the user must be created and managed separately in each partition. This user must use a separate client configuration to start a separate client session for each partition. Each user is associated with a default partition. This default partition can be changed by a system administrator. A user who logs on to Microsoft Dynamics AX by using a default client configuration is logged on to the user's default partition. The Microsoft Dynamics AX client application displays the partition key for the current session in the title bar of the main window. User roles are assigned for each partition.

 Information above is shared based on my experience with Partitions and several online sources. Happy Daxing.